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(57) An automated banking machine (12) is operative to conduct transactions in response to HTML documents and 
TCP/IP messages exchanged with a local computer system (14) through an intranet (16), as well as in response to 
messages exchanged with foreign servers (20, 22, 24, 26, 28, 96) in a wide area network (18). The banking machine 
includes a computer (34) having an HTML document handling portion (76, 80, 82). The HTML document handling 
portion is operative to communicate through a proxy server (88), with a home HTTP server (90) in the intranet or the 
foreign servers in the wide area network. The computer further includes a device application portion (84) which 
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interfaces with the HTML document handling portion and dispatches messages to operate devices (36) in the 
automated banking machine. The devices include a sheet dispenser mechanism (42) which dispenses currency as well 
as other transaction devices. The device application portion communicates with a device interfacing software portion 
(64) in the banking machine through a device server (92) in the intranet. The device server maintains local control over 
the devices in the banking machine including the sheet dispenser. The banking machine operates to read indicia on the 
user's card corresponding to a system address. The computer is operative to connect the banking machine to the home 
or foreign server corresponding to the system address, which connected server operates the banking machine until the 
completion of transactions by the user. 
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TECHNICAL FIELD 

This invention relates to automated banking machines. Specifically 
this invention relates to an automated banking machine apparatus ami system 
that is capable of use in a wide area network, which provides a user with a 
familiar interface from their home institution at banking machines operated by 
other institutions, and which provides greater options for machine outputs. 



BACKGROUND ART 



Automated banking machines are well known, A common type of 
automated banking machine used by consumers is an automated teller machine 
("ATM"). ATMs enable customers to carry out banking transactions. 
Common banking transactions that may be carried out with ATMs include the 
dispensing of cash, the making of deposits, the transfer of funds between 
accounts, the payment of bills and account balance inquiries. The type of 
banking transactions a customer can carry out are determined by capabilities 
of the particular banking machine and the programming of the institution 
operating the machine. Other types of automated banking machines may 
allow customers to charge against accounts or to transfer funds. Other types 
of automated banking machines may print or dispense items of value such as 
coupons, tickets, wagering slips, vouchers, checks, food stamps, money 
orders, scrip or travelers checks. For purposes of this disclosure an automated 
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banking machine or automated transaction machine shall encompass any 
device which carries out transactions including transfers of value. 

Currently ATMs arc operated in proprietary communications networks. 
These networks interconnect ATMs operated by financial institutions and 
other entities. The interconnection of the networks often enables a user to use 
a banking machine operated by another institution if the 
foreign institution's banking machine is interconnected with the network that 
includes the user's institution. However when the customer operates the 
foreign institution's machine the customer must operate the machine using the 
customer interface that has been established by the foreign institution for its 
banking machines. In addition the user is limited to the transaction options 
provided by the foreign institution. 

A customer may encounter difficulties when using a foreign 

institution's machine. Problems may occur because the user is not familiar 

with the type of machine operated by the foreign institution. Confusion may 

result because the customer does not know which buttons or other mechanisms 

to actuate to accomplish the desired transactions. The transaction flow for a 

customer at a foreign institution machine may be significantly different from 

machines operated by the user's home institution. This may be particularly a 

* 

problem when the user is from another country and is not familiar with the 
type of banking machine or the language of the interface provided by the 
foreign institution. Likewise, the documents which are printed by printers in 
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an automated bunking machine are generally limited to a limited group of 
defined formats in a single language. 

A foreign institution may also provide different types of transactions 
than the user is familiar with at their home institution. For example the user's 
5 home institution may enable the transfer of funds between accounts through 
their automated banking machines, to enable the user to maintain funds in 
higher interest bearing accounts until they are needed. If the foreign 

institution does not provide this capability, the user will be unable to do this 
when operating the foreign machine. The inability of a user at a foreign 
1 0 machine to conduct the transactions that they are accustomed to may present 
problems. 

The networks that operate automated teller machines and other types of 
automated banking machines generally operate proprietary networks to which 
access is restricted. This is necessary to prevent fraud or tampering with the 

15 network or user's accounts. Proprietary networks are also generally used for 
the transmission of credit card messages and other financial transaction 
messages. Access to such credit card processing systems is also restricted 
primarily for purposes of maintaining security. 

Communication over wide area networks enables messages to be 

20 communicated between distant locations. The best known wide area network 
is the Internet which can be used to provide communication between 
computers throughout the world. The Internet is not widely used for financial 
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transaction messages because il is not a secure system. Messages intended for 
receipt at a particular computer address may be intercepted at other addresses 
without detection. Because the messages may be intercepted at locations that 
are distant in the world from the intended recipient, there is potential for fraud 

5 and corruption. 

Companies are beginning to provide approaches for more secure 
transmission of messages on the Internet. Encryption techniques are also 
being applied to Internet messages. However the openness of the Internet has 
limited its usefulness for purposes of financial messages, particularly financial 

10 messages associated with the operation of automated banking machines. 

Messages in wide area networks may be communicated using the 
Transmission Control Protocol/Internet protocol ('TCP/IP"). U.S. Patent No. 
5,706,422 shows an example of a system in which financial information stored 
in databases is accessed through a private wide area network using TCP/IP 

1 5 messages. The messages transmitted in such networks which use TCP/IP may 
include "documents" (also called "pages"). Such documents are produced in 
Hypertext Markup Language ("HTML") which is a reference to a type of 
programming language used to produce documents with commands or 'tags" 
therein. The tags are codes which define features and/or operations of the 

20 document such as fonts, layout, imbedded graphics and hypertext links. 

HTML documents are processed or read through use of a computer program 
referred to as a "browser". The tags tell the browser how to process and 
control what is seen on a screen and/or is heard on speakers connected to the 
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computer running the browser when the document is processed. HTML 
documents may he transmitted over a network through the Hypertext Transfer 
Protocol ("HTTP"). The term "Hypertext" is a reference to the ability to 
embed links into the text of a document that allow communication to other 

5 documents which can be accessed in the network. 

Thus there exists a need for an automated banking machine and system 
that can be used in a wide area network such as the Internet while providing a 
high level of security. There further exists a need for an automated banking 
machine and system which provides a user with the familiar interface and 

1 0 transaction options of their home institution when operating foreign institution 
machines. There further exists a need for a machine which may provide more 
transaction options and types of promotional and printed materials to users. 



DISCLOSURE OF INVENTION 



It is an object of the present invention to provide an automated banking 
1 5 machine at which a user may conduct transactions. 

It is a further object of the present invention to provide an automated 
banking machine that may be operated through connection to a wide area 
network. 

It is a further object of the present invention to provide an automated 
20 banking machine and system that provides a user with a familiar interface and 
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transaction options of their home institution al machines operated by foreign 
institutions. 

It is a further object of the present invention to provide an automated 
banking machine that communicates using HTML documents and TCP/IP 
5 messages. 

It is a further object of the present invention lo provide an automated 
banking machine that enables the connection of the banking machine to a 
user's home institution through HTML documents and TCP/IP messages 
generated responsive to indicia on a card input by a user. 
10 It is a further object of the present invention to provide an automated 

banking machine and system that accomplishes transactions over a wide area 
network while maintaining a high level of security. 

It is a further object of the present invention to provide an automated 
banking machine and system that controls connection of the banking machine 
1 5 to foreign addresses through a proxy server. 

It is a further object of the present invention to provide an automated 
banking machine that limits the operation of devices in the machine through a 
local device server. 

It is a further object of the present invention to provide an automated 
20 banking machine and system that is operable through connection to the 
Internet. 
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It is a further object of the present invention to provide an automated 
hanking machine that may be used to provide a user will) more types of 
messages including messages targeted to particular users. 

It is a further object of the present invention to provide an automated 
5 banking machine which is capable of providing users with a wider variety of 
printed documents. 

It is a further object of the present invention to provide an automated 
banking machine which provides additional options for identifying authorized 
users. 

10 It is a further object of the present invention to provide an automated 

banking machine that can be used in connection with existing transaction 
systems while providing enhanced functionality. 

It is a further object of the present invention to provide an automated 
banking machine which provides enhanced diagnostic and service capabilities. 
15 It is a further object of the present invention to provide an automated 

banking machine which performs transactions at a rapid pace. 

It is a further object of the present invention to provide improved 
systems in which automated banking machines are used. 

It is a further object of the present invention to provide improved 
20 methods of operation for automated banking machines and systems. 

Further objects of the present invention will be made apparent in the 
following Best Modes for Carrying Out Invention and the appended Claims. 
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The foregoing objects are accomplished in a preferred embodiment of 
the invention by an automated banking machine that includes an output device 
such as a display screen, and an input device such as a touch screen or a 
keyboard. The banking machine further includes devices such as a dispenser 

5 mechanism for sheets of currency, a printer mechanism, a card reader/writer, a 
depository mechanism and other physical transaction function devices that are 
used by the machine to accomplish banking transactions. 

The banking machine further includes a computer. The computer is in 
operative connection with the output devices and the input devices, as well as 

10 with the sheet dispenser mechanism, card reader and other physical transaction 
function devices in the banking machine. The computer includes software 
programs that are executable therein. The software programs include an 
HTML document handling portion. The HTML document handling portion 
operates to send and receive HTML documents and HTTP messages. The 

1 5 HTML document handling portion is preferably in connection with the output 
device to display screens including hypertext link indicators. The HTML 
document handling portion is also preferably in connection with the input 
device which enables user selection and the generation of response messages 
from the computer. The HTML document handling portion preferably 

20 operates in connection with a JAVA software environment and has the 

capability of executing instructions in JAVA script transmitted with HTML 
documents. 
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The software in Ihe computer further preferably includes a device 
application portion. The device application portion includes software that is 
operative to control the sheet dispenser and other devices. In the preferred 
form of the invention the device application portion includes a plurality of 
5 JAVA applets for operating the devices in the machine. 

The computer in the automated banking machine further includes a 
device interfacing software portion. The device interfacing software portion 
operates to receive messages from the device application portion and to cause 
the devices to operate through appropriate hardware interfaces. In one 
1 0 preferred form of the automated banking machine, the HTML document 

handling portion, device application portion and device interfacing software 
portion each reside on the same computer and communicate at different IP 
ports. 

The automated banking machine of the invention in one configuration 
1 5 communicates using TCP/IP messages in an intranet which includes a 

plurality of such machines. The intranet is in turn connected to at least one 
computer which is operated by a home institution. The home institution is the 
entity that operates the banking machines. 

The computer of the home institution preferably includes a home 
20 HTTP server, a proxy server and a device server. The proxy server 

communicates through the intranet with the HTML document handling portion 
of the software in each of the banking machines. The proxy server is also 
connectable to a wide area network, such as the Internet, to which foreign 
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servers are connected. The device server is operative to pass messages 
between the device application portion and the device interfacing software 
portion of the banking machines. The device server may include monitor 
software which monitors and selectively limits the use and operation of the 
devices in the banking machine. This provides a level of security. 

The automated banking machine and system is operative to place a 
user in connection with the institution where they have their accounts. This 
can be either the home institution that operates the banking machine where the 
user is present, or a foreign institution which is connected to the wide area 
network. To operate the banking machine a user provides inputs which 
correspond to an address, such as a URL address, through an address input 
device. The HTML document handling portion operates to connect the 
banking machine to the server corresponding to that address. This is 
preferably accomplished by the user having indicia representative of the 
address on a card that is read by a card reader in the banking machine, or other 
input device which identifies the user or an institution or entity with which the 
user has accounts. 

The HTML document handling portion is responsive to the address on 
the card or other input data to connect through the proxy server to the user's 
institution. If the user's home institution address corresponds to the home 
server, the banking machine operates responsive to messages from the home 
server. If however the user's input address corresponds to an address of a 
foreign server, the proxy server is operative to communicate through the wide 
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area network with the foreign server at the customer's home institution. If the 
customer causes the machine to connect a server operated by a foreign 
institution, the HTML documents sent from the foreign institution correspond 
to those normally provided by the foreign institution. As a result the customer 
5 is familiar with the interface produced by these documents and will be able to 

more readily operate the banking machine. 

The foreign server or home server operate the banking machine by 
sending HTML documents that include instructions for operating the devices 
in the banking machine. The instructions are transmitted from the HTML 
1 0 document handling portion to the device application portion of the software, 
which operates the devices in response to the instructions. The instructions 
from the device application portion to the devices in the automated banking 
machine are passed through the device server of the home institution. This 

4 

helps to maintain security. In addition, the proxy server includes screening 
1 5 software which limits the foreign servers which may connect to and operate 

the banking machine. This is referred to as a "fire wall." 

Embodiments of the present invention also provide enhanced user 

interfaces and for the printing of a wide variety of documents with the banking 

machine. The invention also enables achieving enhanced functionality while 
20 utilizing existing transaction networks and automated transaction machines. 



BRIEF DESCRIPTION OF DRAWINGS 
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Figure 1 is a schematic view of a network configuration including the 
automated banking machine apparatus and system of the present invention. 

Figure 2 is a schematic view of a preferred embodiment of an 
automated banking machine ofthe present invention. 
5 Figures 3 through 24 show schematic views ofthe automated banking 

machine, an intranet connecting the banking machine to a computer system of 
a home bank and a wide area network connecting the computer syslem ofthe 
home bank to a foreign bank. 

Figures 3 through 18 schematically represent steps in a transaction 
1 0 carried out at the banking machine with the computer system of the home 
bank. 

Figures 19 through 24 schematically represent steps in a transaction 
carried out at the banking machine with the computer system of the foreign 
bank. 

1 5 Figure 25 is a schematic view of a network configuration including an 

alternative embodiment of the automated banking machine of the present 
invention. 

Figure 26 is a schematic view of frames in the HTML document 
handling portion of the alternative embodiment of the automated banking 
20 machine shown in Figure 25. 

Figure 27 is a schematic view of a customer interface of an automated 
banking machine and the function keys and keypad keys included in the 
interface. 
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Figures 28-30 schematically represent exemplary steps in converting 
function key and keypad key inputs to keyboard stream and mouse stream 
inputs. 

Figure 31 schematically represents exemplary steps in printing 
5 documents with the automated hanking machine. 



BEST MODES FOR CARRYING OUT INVENTION 

Referring now to the drawings and particularly to Figure 1 , there is 
shown therein a network configuration schematically indicated 10, which 
includes the automated hanking machine apparatus and system of one 

1 0 preferred embodiment of the present invention. Network 1 0 includes a 
plurality of automated banking machines 12 which in the preferred 
embodiment of the invention are ATMs. ATMs 12 are connected to a 
computer system of a home bank schematically indicated 14. Home bank 
computer system 14 is the computer system that is operated by the bank or 

15 other institution which has primary responsibility for the ATMs 12. Home 

bank computer system 14 is connected to the ATMs 12 through an intranet 16. 
Intranet 16 is preferably a local or proprietary network that provides 
communication between the computer system 14 and the banking machines 12 
using messages in the transmission control protocol/internet protocol 

20 ("TCP/IP") format. 
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The messages that are communicated through the intranet 16 are 
preferably TCP/IP messages and hypertext mark up language ("HTML") 
documents. In one preferred embodiment of the invention the HTML 
documents sent through intranet 16 include embedded object oriented 
5 programming instructions, preferably in the JAVA® format which has been 

developed by Sun Microsystems. The messages sent through intranet 16 may 
be sent in an encrypted or unencrypted form depending on the nature of the 
system and the security needs of the home bank. 

It should be understood that embodiments of the invention may 

10 process other forms of documents which include lags or instructions therein. 
For example a form of "extended" HTML has recently been proposed which 
may be used in embodiments of the invention. For purposes of the invention 
all such forms of languages and variants which include documents, which 
documents include instructions therein shall be referred to as HTML 

1 5 documents. Likewise, while JAVA® is used in the described embodiment, 

other programming languages may be used. For example, Active-X™ 
developed by Microsoft Corporation or other languages may be used in other 
embodiments. Further it should be understood that the instructions included in 
documents may be operative to cause a computer to access other documents, 

20 records or files at other addresses to obtain a program to carry out an 
operation. 

Home bank computer system 14 is also connectable as shown to a wide 
area network 1 8. In some embodiments of the invention the wide area 
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network 18 is the Internet. In oilier embodiments of the invention, other wide 
area networks may be used. The wide area network preferably communicates 
messages in TCP/IP between numerous computer systems connected to the 
wide area network. These foreign computer systems are schematically 
5 represented by servers 20, 22, 24, 26 and 28. It should be understood that 
servers 20 through 28 may be operated by or connected to other financial 
institutions throughout the world. Servers 20 through 28 preferably operate by 
communicating HTML documents and other HTTP messages. 

Figure 2 shows a schematic view of the ATM 12 used in connection 

10 with one preferred embodiment of the invention. ATM 1 2 includes a touch 
screen 30. Touch screen 30 includes a display screen which serves as an 
output device for communication with a user of the machine. Touch screen 
30, because it is a touch screen, also serves as an input device for receiving 
input instructions from a user. Touch screen 30 is connected through an 

1 5 interface 32 to a computer 34 which is preferably housed within the machine. 

Alternative embodiments of the invention may include other output devices 
such as audio speakers. 

Computer 34 is also in connection with a plurality of transaction 
function devices 36 which are included in ATM 12. Devices 36 include for 

20 example, a card reader/writer mechanism 38 and a keyboard 40. Devices 36 
further include a sheet dispenser mechanism 42 which is operative to dispense 
sheets, which in some preferred forms of the invention are currency or bank 
notes. Devices 36 also include a depository 44 for accepting deposits into a 
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secure location in Ihe machine. A receipt printer 46 for providing transaction 
receipts to customers is also included among devices 36. A journal printer 48 
is also included among the devices for keeping a hard copy record of 
transaction information. In other embodiments other or additional transaction 

5 function devices which cany out other transaction functions may be used. 

Other embodiments may include fewer transaction function devices. It should 
be further understood that while the described embodiment of the invention is 
an automated banking machine, the principles of the invention may be 
employed in many types of transaction machines that do not necessarily carry 

1 0 out banking transactions. 

Each of the devices is operatively connected to an internal control bus 
50 within the banking machine 12. The control bus 50 outputs the internal 
messages to the particular devices. Each device has an appropriate hardware 
interface which enables the particular device to operate to carry out its 

1 5 respective function in response to the messages transmitted to it on control bus 

50. Card reader/writer 38 has a hardware interface schematically shown as 52. 
Hardware interfaces 54, 56, 58, 60 and 62 are respectively operative to 
connect keyboard 40, sheet dispenser mechanism 42, depository mechanism 
44, receipt printer mechanism 46 and journal printer mechanism 48 to the 

20 control bus 50. 

Computer 34 has several software programs that are executable 
therein. In the preferred embodiment of the invention these software programs 
include a device interfacing software portion generally indicated 64. Device 
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interfacing software portion 64 preferably includes a software device interface 
66 that communicates electronic messages with the control bus 50. The 
device interface software portion 64 also preferably includes a device manager 
68. The device manager is preferably operative to manage the various devices 
5 36 and to control their various states so as to be assured that they properly 

operate in sequence. The device manager is also preferably operable to create 
device objects in the software so as to enable operation of the devices by at 
least one object oriented program 70. Device interfacing software portion 64 
also includes the object oriented program portion 70, which in one preferred 

10 embodiment is an application written in the JAVA language. Program 70 
works in conjunction with the device manager to receive object oriented 
JAVA messages which cause the devices to operate, and to transmit device 
operation messages indicative of a manner in which devices are operating 
and/or are receiving input data. 

1 5 The device interfacing software portion 64 in the described 

embodiment operates on computer 34 and communicates through a physical 
TCP/IP connection 72 with the intranet 16. The physical connection may be 
analog dial-up, serial port, ISDN connection or other suitable connection. In 
the configuration of the system as shown, device interfacing software portion 

20 64 communicates at the IP address of computer 34 and at an IP port or socket 
indicated 74 that is different from the other software applications. In other 
embodiments of the invention, device interfacing software portion 64 may 
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operate in a different computer than the other software applications of the 
invention. 

It should further be understood that although in the preferred 
embodiment of the invention the device interfacing portion 64 is software, in 
other embodiments of the invention all or portions of the instruction steps 
executed by software portion 64 may be resident in fimiware or in other 
program media in connection with one or more computers, which are 
operative to communicate with devices 36. For purposes of the invention all 
such forms of executable instructions shall be referred to as software. 

Other software also operates in computer 34. This software includes 
HTML document handling software which includes a browser, schematically 
indicated 76. In the preferred embodiment of the invention the HTML 
document handling software includes a browser provided by Netscape®. 
However in other embodiments other HTML document handling and 
communicating software and browser software, such as Hot JAVA® by Sun 
Microsystems or Internet Explorer™ from Microsoft, may be used. Browser 
76 communicates in computer 34 at an IP port indicated by 78. 

Browser 76 is in operative connection with JAVA environment 
software 80 which enables computer 34 to run JAVA language programs. 
JAVA language programs have the advantage that they operate the same on a 
variety of hardware platforms without modification. This "write once\run 
anywhere" capability makes the JAVA environment well-suited for the 
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described embodiment of the invention. However other embodiments may use 
different types of software programs. 

The JAVA environment software 80 enables computer 34 to execute 
instructions in JAVA script, schematically indicated 82. The instructions that 
5 are executed by the computer in JAVA script are preferably embedded JAVA 
script commands that are included in the HTML documents which are 
received through the browser 76. The browser 76 in connection with the 
JAVA environment software 80 which executes instructions in the embedded 
JAVA script 82, serve as an HTML document handling software portion for 

1 0 transmitting and receiving HTML documents and TCP/IP messages through 
the IP port indicated by 78. 

Computer 34 also has executable software therein having a device 
application portion 84. The device application portion 84 contains executable 
instructions related to operation of the devices 36. In the preferred 

15 embodiment of the invention, the device application portion consists of a 

plurality of JAVA applets. In the described embodiment the applets are also 
preferably programs operable to control and keep track of the status of the 
devices with which they are associated. Certain applets are also preferably 
operable to configure the browser to communicate messages. Certain applets 

20 manage security and authenticate entities that use the ATM. 

In the described form of the invention, JAVA applets are associated 
with functions such as enabling the card reader mechanism, notifying the 
browser when a user's card data has been entered, operating the receipt printer 
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mechanism, operating the journal printer mechanism, enabling the customer 
keyboard and receiving data input through the keyboard, operating the sheet 
dispenser mechanism, operating the depository, navigating to document 
addresses, timing device functions, verifying digital signatures, handling 
encryption of messages, controlling the mix of bills dispensed from multiple 
sheet dispenser mechanisms, calculating foreign exchange, and ending a 
transaction and instructing the browser to return to communication with the 
home server. Of course, in other embodiments, other applets may be used to 
control devices and use data to carry out various desired functions with the 
machine. The device application portion 84 communicates in the computer 34 
at an IP port indicated 86. 

In the described embodiment of the invention, the device application 
portion 84 of the software does not communicate its messages directly to the 
device interfacing software portion 64. As later explained, this provides 
heightened security. However it should be understood that embodiments of 
the invention may provide for the device application portion 84 to directly 
communicate device operation messages to the device program 70. This may 
be done either internally using TCP/IP, by delivery of messages in a 
conventional manner through a queue established in the operating system of 
the computer that is associated with the software that interfaces with the 
devices, or by direct call to this software. 

From the foregoing discussion it will also be appreciated that certain 
applets in the device application portion 84 may correspond to devices which 
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are not present in all automated teller machines. For example an automated 
teller machine that operates only as a cash dispenser does not include a 
depository mechanism like depository 44. To accommodate the situation 
where a user requests a transaction that is not physically possible with the 
5 ATM 12, the device interfacing software portion 64 may be programmed to 
provide an appropriate response message to indicate that the function is not 
available. 

Alternatively, the device interfacing software portion may include a 
function which checks for the presence or absence of each type of physical 

10 device within the ATM. Information indicative of the devices present in the 
ATM may be included as part of the messages generated by the ATM. For 
example, information indicative of the devices which are operative in the 
ATM may be included as a portion or several parts of the URL addresses to 
which messages are directed by the ATM. In this way, the URL in the server 

1 5 to which the ATM connects may be configured for providing only HTML 

documents which correspond to the types of transactions that the ATM is 
capable of performing. As a result the browser avoids displaying documents 
which include references to transaction types that the machine is not capable 
of performing. Thus for example, a machine may avoid producing a display in 

20 response to a document which includes a reference to a deposit transaction if 
the machine does not include a depository. 

Alternatively the machine may include in memory, data representative 
of the functional devices included in the machine. This may include for 
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example dala representative of a plurality of devices in the machine and the 
configurations of such devices, or alternatively, a designator such as a machine 
number sufficient to identify the capabilities of the machine. The device data 
indicative of the functional devices in the machine is communicated to a 
5 server and the server is operative to deliver the appropriate HTML documents 
for the devices present in the machine. This may be done based on the data 
corresponding to the device data from the machine or may be resolved from a 
memory which holds data representative of the functional devices in a 
machine associated with a particular designator. Documents selectively 

1 0 delivered by the server to the browser of the machine will include the 

appropriate references to the functional devices present in the machine. These 
documents may be static documents or may be generated at run time from sub- 
documents or otherwise, to provide the appropriate outputs and instructions to 
the output devices of the transaction machine. 

1 5 Figure 3 shows the ATM 1 2 in communication through the intranet 1 6 

with the home bank computer system 14. Computer system 14 includes a 
proxy server 88. System 14 farther includes a home HTTP server 90. 
Computer system 14 further includes a device server 92. The proxy server, 
home HTTP server and device server may be included in a single computer as 

20 shown, or in other embodiments may be separate computers. Additional 
servers may be operative in other embodiments. 

The home HTTP server 90 is preferably in communication with a data 
store and is in electronic communication with a back office computer system, 
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schematically indicated 94. Back office computer system 94 is operative to 
keep track of debiting or crediting customers' accounts when they conduct 
transactions at the automated hanking machines. In addition hack office 94 is 
also prefcrahly operative to track transactions for purposes of accomplishing 
5 settlements with other institutions who are participants in the system and 
whose customers conduct transactions at the ATMs 12. 

As later explained, proxy server 88 is also operative in the described 
embodiment to communicate through the wide area network 18 with foreign 
servers such as foreign server 96. Foreign server 96 is an example of a server 

1 0 operated by an institution or entity other than the institution which operates 
computer system 14. It should be understood that while foreign server 96 is 
indicated as operated by a "foreign" institution, this is not necessarily 
indicative that the institution is located in another country from the institution 
that operates computer system 14. However, it is possible that foreign server 

1 5 96 could be located in such a foreign country, including a country in which the 

language spoken is different from that generally used in the country where 
ATM 12 is located. 

The conduct of transactions using the ATM 12 is now explained with 
reference to Figures 3-24. It should be understood that the following 

20 described transaction flows are merely examples of the operation of the 

apparatus and system, and the apparatus and system may be configured and 
operated in numerous ways to carry out transactions. 
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At the start of an exemplary transaction, as schematically represented 
in Figure 3, the browser 76 communicates through the intranet 16 with the 
proxy server 88. The communication is established preferably in a manner so 
that HTML documents intended to attract customers to the ATM 12 are 

5 displayed on the touch screen 30. This is referred to as the "attract mode. 0 
These HTML documents which are processed in the browser lo produce the 
outputs in the form of screens on the touch screen 30 (and/or outputs through 
other output devices included in the machine) may originate from home HTTP 
server 90 which is operative to deliver the HTML documents to the proxy 

10 server. The home HTTP server sends the messages addressed to the IP port 
associated with browser 76, so as to cause their display at the proper ATM 
machine. It should be understood that while in this example, home server 90 
is described as communicating with the ATMs through the proxy server 88, 
the server 90 may in other systems encompassed by the invention 

1 5 communicate directly with the ATMs. 

A fundamental advantage of the system is that home HTTP server 90 
may deliver documents selectively to the ATMs 12 connected to the intranet 
16. These documents may include messages or material tailored to the 
particular location in which an ATM 12 is located. Examples of particularly 

20 tailored screens may include bilingual messages in certain neighborhoods or 
information concerning currency exchange at various ports of entry. The 
material or messages could include advertising for various products or services 
or other material targeted to particular machine locations. The JAVA applets 
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and JAVA script are loaded from a central location providing selective 
software distribution in the ATMs which may also be used to tailor the ATM 
to its environment by causing it to access documents which include material 
intended to he useful in that location, and which is not provided in documents 

5 delivered to at least some other machines in the system. 

Systems of the present invention may be configured to have selected 
machines access HTML documents at different addresses, so that the 
particular documents accessed include the material targeted to users of the 
particular machine. Alternatively, a machine may communicate machine data 

1 0 indicative of its identity and/or location to a server. From the machine data, 

and data stored in a data store in connection with the server, the server 
operates to deliver the documents including the targeted material. This may 
be accomplished by assembling subdocuments, or otherwise, to generate the 
documents that will be delivered to the browser of the particular machine. In 

1 5 addition it should be understood that while in the embodiment shown the 

HTML documents are accessed through a server of an institution associated 
with the machine, the documents used for the attract mode may be accessed 
from other servers operated by other entities. 

The touch screen30 in this exemplary transaction sequence displays a 

20 screen which includes an icon which indicates in one or more languages that to 
commence a transaction a user should touch the screen. If a user touches the 
screen in the area of the icon an input signal is generated. The input signal or 
HTTP message is transmitted through the browser 76 to the home address of 
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the home HTTP server 90 to which the ATM 12 is currently in 
communication. The message generated back to the home 1 1TTP server is 
represented by the arrows directed from the browser 76 to the intranet 16, 
from the intranet 16 to the proxy server 88, and from the proxy server to the 

5 HTTP server 90 in Figure 3. 

In response to the home HTTP server 90 receiving the message 
indicating Chat a customer has touched the icon on the screen, the home server 
is operative responsive to the address accessed to send a message through the 
proxy server 88 (or in other embodiments directly) to the browser 76. This 

10 message preferably includes an HTML document which when processed 

through the browser produces a screen instructing the customer to insert their 
card into the card reader mechanism 38. The HTML document flow which is 
represented graphically in Figure 4, preferably also includes embedded JAVA 
script or other instructions which operate in the JAVA environment to 

1 5 communicate a message to the JAVA applet responsible for enabling the card 
reader in the device application portion 84. In one preferred embodiment the 
instructions provide a pointer or tag to the applet which executes responsive to 
receipt of the document instructions. Of course in other embodiments other 
software and approaches may be used. 

20 As shown in Figure 5, in response to the embedded JAVA script 

activating the JAVA applet associated with the enable card reader function, 
the JAVA applet in the device application portion 84 communicates with the 
device server 92. The device server 92 includes a device server program 98 
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which in the preferred embodiment is a JAVA program thai enables 
communication with the JAVA applets and the device server application 1 00. 
The device server 92 further preferably includes a monitor software 
application 102 which is operative to monitor device operation instructions. 
The monitor software minimizes the risk of fraud or abuse in a manner later 
explained. 

Returning to the sample transaction, in response to receiving the enable 
card reader message from the device application portion 84, the device server 
92 is operative to generate a message through the intranet 16 to the device 
interfacing software portion 64 of the ATM 12. This message which 
comprises an HTTP record including instructions for operating the card reader, 
is directed to the IP port indicated 74 which is where the device interfacing 
software portion 64 communicates. In response to receiving this message, the 
software portion 64 is operative to send a message or messages on the control 
bus 50 which enables card reader mechanism 34. 

Continuing with the transaction as shown in Figure 6, the input of the 
card by the customer to the card reader 34 is operative to cause the card data to 
be read and the device interfacing program portion 64 to send a message to the 
device server 92 indicating the card data has been read. This message is 
transmitted by the device server through the intranet 16 to the device 
application portion 84. The device application portion then sends a message 
to the device server requesting the card data. The device server 92 transmits a 
message with instructions to deliver the card data from the device interfacing 
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software portion 64 which responds with a message sending the card data 
through the intranet to the device server. The device server, if there is no basis 
Tor stopping the transaction, transmits an HTTP record including card data 
back through the intranet 16 to the device application portion 84. 
5 In one preferred embodiment of the invention, the card input by a user 

or customer includes indicia which corresponds to an address associated with 
the user in the network. In such an embodiment the indicia corresponds to a 
uniform resource locator ("URL") address which provides information on the 
computer where the user information resides, as well as a directory or 

10 subdirectory which includes the user information and the name of the 

document or resource that includes the user information. The URL address 
may be encoded on a customer's card. The address may be encoded on track 3 
of a magnetic stripe, in other locations within the magnetic stripe data or 
through encoding other readable indicia on the card. Alternatively, if the 

15 customer's card is a "smart" card which includes semiconductor storage 

thereon, the URL address associated with the customer may be included as 
part of the stored data on the integrated circuit chip on the customer's card. 
Alternatively, a URL could be derived from other data on the card by 
accessing a data base in which address data is correlated with other data read 

20 from the card. The data necessary to derive the address for accessing 

documents associated with a customer could also be derived from inputs to 
input devices other than or in addition to card data, including for example 
biometric data which is input by a customer through a biometric reading 
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device. Such biomclric dala may include for example, data corresponding lo 
one or more fingerprints, dala from Ihe user's appearance or combinations 
1 hereof. 

For example and without limitation, data input by a customer such as 
5 through a card input lo a card reader may correspond to an address for 

accessing an HTTP record, which may be a file or document which includes 
information which can be used for verifying the identity of a user. This record 
could include data corresponding to a PIN number. The information may 
include biometric data corresponding to the authorized user of the card. The 

10 browser may access the record and use the contents of the record such as dala 
and/or instructions to verify that the indicia corresponding to biometric data in 
the record corresponds to the biometric data of the user entering the card. 
Alternatively, input data representative of appearance, voice, other features (or 
combinations thereof) or other input data, may be used to generate one or 

1 5 more addresses which correspond to a user, and the content of the record at the 
accessed address used to verify that the user at the machine corresponds to the 
user associated with the record. Numerous approaches within the scope of the 
invention may be used. The information in the record corresponding to a user 
may likewise be used to authorize certain functional devices on the machine to 

20 operate for the user while other devices may not. For example, a user who is 
overdrawn may have information in the record accessed that prevents them 
from actuating the cash dispenser, while users who are not overdrawn may 
include information which enables such operation. Alternatively, the absence 
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of information in a corresponding record may enable operation, while the 
inclusion of information sclcclivcly limits the operation of devices. 

Reluming to the exemplary transaction, the delivery of the card data 
from a successfully read card is delivered responsive to the programming of 
5 the device application portion 84 to a JAVA applet associated with notifying 

that the card data has hcen entered. In response, (he JAVA applet operates to 
generate JAVA script which configures the browser with the URL address 
corresponding to the data read from the card. The JAVA applet is also 
preferably operative lo open a record schematically indicated 104 concerning 

10 the transaction, which includes the user's URL address, the time and other card 
data. This record in a preferred embodiment may be stored in memory as data 
in an object in software. The object is preferably used to accumulate data as 
the transaction proceeds. The data stored in the transaction data object 
preferably includes data input through input devices by the user as well as data 

1 5 representative of operations carried out by transaction function devices. 

The record or transaction data object provides persistence through what 
may be several different transaction steps executed by the customer. The 
ability to use and share the data in a number of different operations avoids the 
need to derive it or obtain it from a customer more than once in the course of a 

20 user session involving a number of transaction steps. The use of a transaction 
data object enables applets to run largely independently, obtaining needed data 
from the transaction object. The approach also enables the record or data 
object to be used to produce an appropriate record at the end of the transaction 
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session. This record may be stored, collected into a batch or delivered to 
selected addresses in a local or wide area network. 

As schematically shown in Figure 7, in response to the browser 76 
receiving the URL address data, the browser is operative to transmit a message 
5 through the intranet 16 to the proxy server 88. For purposes of this example, 

the URL address associated with the card data is that of a customer associated 
with the home bank which operates system 14. As a result, the customer's 
URL address will cause the message to be directed from the proxy server 88 to 
the home HTTP server 90 and to access the corresponding document at the 

1 0 address therein. Alternatively, in other systems the connection may be made 
directly with server 90 without the intervening proxy server 88. As previously 
discussed, the URL address may also include data representative of the 
devices which are operative in the ATM. 

In response to receiving the message, home HTTP server 90 finds the 

1 5 data corresponding to the customer's URL address data in its associated 

memory and delivers to the browser at its IP port with an HTML document. 
This HTML document may include a screen acknowledging the particular 
customer by name as well as with the name of the banking institution or other 
entity which operates the home bank computer system 14. 

20 In addition, the HTML document preferably includes embedded JAVA 

script which has a digital signature or a means to obtain a digital signature 
associated with the home HTTP server 90. The script instruction included in 
the document in certain embodiments causes the device application portion to 
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access iin 1 1'ITP ailitrcss on a server, which in the described embodiment is 
server 90. The I ITTP address corresponds lo an I ITTP record which includes 
at least one instruction and preferably includes a program such as a JAVA 
applet or Active- X file. The instruction is used to operate the appropriate 

5 transaction function device. The HTTP record preferably includes data 

representative of u signature, such as a digital signature. This digital signature 
is received responsive to the JAVA script 82 and processed in the device 
application portion 84. A JAVA applet processes the digital signature to 
authenticate it and if it is an acceptable signature authorizes operation of the 

10 banking machine. In certain embodiments the applet may compare the 

signature to signature data stored in memory for a predetermined relationship, 
such as a match. 

After the applet verifies that HTTP server 90 or other accessed HTTP 
record has sent a proper digital signature, the transaction will be allowed to 

1 5 continue. If for some reason a proper digital signature has not been sent, the 
JAVA applet will stop the transaction and return banking machine 12 back to 
the condition prior to the start of the transaction by connecting the ATM to the 
address associated with the attract mode in home server 90. The use of signed 
instructions may be used to assure that the various transaction function devices 

20 are only operated in response to appropriate messages. The use of signed 

instructions may be particularly appropriate for instructions that run the sheet 
dispenser or otherwise provide value to the user of the machine. 
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In the example it will be assumed that the digital signature received is 
a proper signature, in which ease a message is returned from the browser 76 to 
home server 90 indicating that the transaction may proceed. As shown in 
Figure 8, in this exemplary transaction the I ITTP home server 90 then 
5 operates to send an I ITML document to the browser 76 which includes 

instructions which when processed produce a page or screen which instructs 
the customer to enter their personal identification number or PIN. This I ITML 
document preferably includes embedded JAVA instructions which operate to 
cause the device application portion 84 enable the keyboard 40 of the ATM so 

10 the machine may receive the PIN number. Such a message is schematically 
shown in Figure 8 with the JAVA script 82 signaling the JAVA applet 
responsible for the keyboard that it has been requested to enable the keyboard. 
In response the JAVA applet in the device application portion 84 sends a 
message through the intranet 16 to the device server 92. The device server 92 

1 5 sends a message back through the intranet to the device interfacing software 

portion 64 in the ATM. The instructions in this message causes the device 
software to enable keyboard 40. The JAVA applet responsible for enabling 
the keyboard is also preferably operative to update the transaction record 104 
to indicate that the PIN was requested. 

20 As shown in Figure 9, the PIN entered through the keyboard 40 is 

transmitted in a message from the device interfacing software portion 64 to the 
device server 92. The device server 92 returns a message to the responsible 
JAVA applet in the device application portion. The JAVA applet then 
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operates lo seiul a message back through the HTML document handling 
portion and the browser 76 lo the I NTP address of home server 90, This 
message includes data representative of Ihe PIN input by the customer. In 
some embodiments it is not desirable to display the customer's PIN on the 

5 screen. In such embodiments Ihe keyboard applet may be operative lo display 
a default character on the screen such as a ***** symbol or other symbol in lieu 
of the PIN digits. Further as later discussed it may be desirable lo avoid 
transmission of PIN or other data through Ihe browser, in which case PIN data 
may be handled as a separate HTTP message or in other manner to reduce the 

10 risk of disclosure. 

The software operating in connection with HTTP server 90 is then 
operative to either verify the PIN itself or to verify the customer's PIN number 
and account number by sending it to the back office 94 and waiting for a 
response. Alternatively, customer PIN verification may be carried out in the 

1 5 ATM through an appropriate applet. This can be done in situations where data 
on a customer's card, such as an account number, can be correlated to the 
customer's PIN number through an algorithm. The embedded JAVA script in 
the HTML messages may include or point to an address to obtain the data 
and/or instructions which the applet uses to perform this verification function, 

20 including certain encryption key data. This may include user information in 
the HTML document or other record data that was accessed in response to the 
user's card data. As shown schematically in Figure 9, the transaction data 
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object 104 is also appropriately updated by the applet to indicate the entry of 
the customer's PIN. 

In alternative embodiments the machine may include a biometric 
reader device or other input device to accept data from a user. The user may 
5 input data through such a device which may be used in lieu of, or in addition 
to, PIN data to verify that the user is an authorized user. This may be done for 
example by comparing the user data input to information corresponding to the 
authorized user of the card included in a record or a document which has an 
HTTP address and is accessed by a browser or by an HTTP client application 

10 through an HTTP server in response to card data. Alternatively input data 
may be used to generate addresses for documents or records which are 
accessed by the browser or client, and which records or documents contain 
information that is used to verify the user's identity. For example, data 
concerning users may be stored in a data store in connection with an HTTP 

15 server, which delivers data from a record responsive to the user data, which is 
used to verify the user's identity. 

It should be noted that the page or screen which requests the customer 
to enter their PIN is shown generated from the home HTTP server 90. This is 
preferably a screen that is associated with the particular customer's URL 

20 address. This will be the interface of the customer's home bank and will be 

familiar to the customer. Alternatively, the customer address may access what 
may be essentially the customer's personal "home page" with the institution 
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that operates computer system 14. As such, it is not only something the user is 
familiar with, but is ideally tailored to the user's particular transaction needs. 

Alternatively, the document(s) or record(s) which contain the customer 
data may be used to generate the addresses for other documents. The 
information may also be used to generate a document for the particular 
customer in the particular circumstances. This approach may be useful to 
reduce the effort associated with developing in advance a personal visual page 
or document for each customer. 

Approaches for accomplishing this may involve including various 
types or categories of user information in the document(s) or record(s) that 
pertain to a particular customer. This may include information such as gender, 
related persons, account types, permitted transactions, customer preferences, 
customer interests, account balances, previous offers declined or accepted and 
other information. This customer information can be used by an appropriate 
applet among applets 86 to address and/or develop an appropriate document 
for the browser to access based on the customer "profile". In addition, the 
profile applet may take into consideration the transaction devices present in 
the particular machine, information on which is stored in a data store in the 
machine or elsewhere in the system, as well as other factors such as the day of 
the week and time of day based on a system clock. In this way the machine 
determines the appropriate document to access or generate for the particular 
customer under the particular circumstances. 
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The logic used in the profile applet may act to cause documents to be 
built or accessed for the customer which includes transaction options based on 
the customer information, information about the terminal and other factors. 
The profile applet may operate to offer transaction options or information 
5 selectively based on the customer information. For example, the operator of 
the machine may offer incentives, premiums, additional transaction options or 
advertising information selectively to customers. Certain types of customers 
of the institution operating the machine may receive screen outputs with 
options that encourage them to do more business or different types of business 

10 with the institution. Likewise, customers that are identified as customers of 
foreign institutions may be provided with incentives to do business with the 
institution operating the machine. 

The profile applet may operate to cause the computer to access other 
documents in other servers, such as stock market data, and selectively provide 

15 it to customers. It should be understood that the profile applet may operate to 

determine an address or generate documents to produce initial display screens 
of a transaction sequence. The profile applet may also operate to provide 
information or access or produce documents to generate visual outputs to the 
customer at other points in a transaction or between transactions. This may 

20 further be used in systems in which the operator of the machine is able to sell 
paid advertising to third parties and then access the HTTP records such as 
HTML files for those third parties' products or services. Such accessing may 
be done based on a periodic or other basis, but may be done effectively by 
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selecting the HTTP record to access in response to the profile of the particular 
customer. 

The continuation of the transaction flow for this exemplary transaction 
by a customer of the institution that operates computer network 14, is 

5 schematically shown in Figure 10. The home HTTP server 90 is operative in 

response to the customer inputting the correct PIN to send HTML documents 
to the HTML document handling portion of the software in the computer 
which operates the ATM. These messages may include information used to 
generate screens which prompt the customer to select a transaction. For 

10 purposes of this example, it will be assumed that the customer inputs at the 
touch screen 30 a selection which corresponds to the dispense of cash, which 
is a common transaction at an automated banking machine. 

The selection of the customer through the input device of the touch 
screen is communicated back through the HTML document handling portion 

1 5 which communicates an HTTP message to the home HTTP server 90. Server 
90 then responds by sending another HTML document to the banking machine 
which prompts the customer to select an amount. Again the customer may 
input a selection on the touch screen which indicates the amount of cash 
requested by the customer. This HTTP message passes through the HTML 

20 document handling portion and the browser 76 to the home server 90. 

In response to the receipt of amount data from the customer, the home 
server 90 is preferably operative to communicate electronically with the back 
office 94 to verify that the customer has the amount requested in their account. 
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This is preferably accomplished through a Common Gateway Interface (CGI) 
106 which is in operative connection with the home server 90. For purposes 
of this transaction it will be assumed that the back office 94 indicates that the 
money is available in the customer's account and sends a message through the 

5 CGI 106 to the home server 90 indicating that it may proceed. 

As schematically represented in Figure 1 1 , the home server 90 then 
operates to send a document back to the HTML document handling portion in 
the ATM software. This message preferably will cause information to be 
displayed on the screen which advises the customer that the transaction is 

10 being processed. In addition the HTML document returned preferably 
includes JAVA script which include embedded instructions which are 
executed and communicated to a JAVA applet associated with the operation of 
the sheet dispensing mechanism 42. 

The document returned from the home server 90 may include 

15 advertising or other information instead of or in addition to the customer 

message. The document returned may also include an instruction which 
causes the machine to access or generate another document. These 
instructions may invoke methods in the profile applet which depend on the 
properties associated with the customer, the machine, the current time and/or 

20 other circumstances. This enables accessing documents that provide 

promotional messages such as advertising or other information to the customer 
while the customer is waiting for the machine to operate. It should be 
understood that these documents may be accessed anywhere, including from 
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the Internet. This makes it possible to selectively present a wide range of 
materials to customers. It also enables operators of ATMs and other 
transaction machines to present advertising to customers, on a broad basis, or 
targeted to categories of customers or even targeted to individual customers on 
5 a segment of one basis. This could be advertising of the machine operator 
such as a bank, or advertising pertaining to virtually any type of goods or 
services. The advertising may also be selectively presented based on the 
particular transaction device being operated, the amount of funds involved or 
other parameters. The HTML documents also enable the presentation of video 
10 and sound to the customer which may enhance the effectiveness of 
promotions. 

The message to the JAVA applet in the device application portion 84 
of the software to initiate operation of the sheet dispenser results in generation 
of a message to the device server 92. The message to the device server 92 to 

1 5 dispense cash is preferably analyzed by the monitor software 1 02 to check to 
see if the message is appropriate. For example the monitor software 102 is 
preferably operative to assure that the amount of cash being requested does not 
exceed a preset amount. It can also optionally check to verify that the amount 
provided to this customer within a prior period has not exceeded an amount. 

20 This may be done by the device server sending a message to the back office 
which includes the card data it has previously received from this customer. 
This message may pass through server 90 and its associated CGI, or other 
connection. Assuming that the dispense instruction is not prevented by a 
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message from the back office or the monitor software, the device server 92 is 
operative to send a dispense message to the device interfacing software portion 
64 in the ATM. The software portion 64 is thereafter operative responsive to 
the message to operate the sheet dispensing mechanism 42 to dispense the 
5 amount of cash requested by the customer. 

The monitor software 102 preferably performs additional functions in 
the device server. For example, government regulations or good business 
practice may require limiting the size and amounts of deposits which may be 
made into an ATM. This may be advisable to prevent "money laundering" or 

10 other suspicious activities. The monitor software preferably operates to limit 
the amount of any single deposit to below a set limit. It further operates by 
communicating with the home bank back office system 94 to prevent a series 
of deposits within a preset time from exceeding a certain limit. The monitor 
software may also work in connection with the proxy server to limit certain 

1 5 transactions that may be carried on at the banking machine responsive to 

instructions from foreign servers as later discussed. 

It should be noted that in a preferred embodiment of the invention the 
JAVA applet which is operative to send the message which causes cash to be 
dispensed, works in connection with another applet which controls the mix of 

20 bills dispensed to a customer. Many automated teller machines have the 

ability to dispense two or more denominations of currency bills. It is desirable 
to control the mix of bills dispensed to a customer to suit that which is 
available in the machine and to avoid running out of one denomination of bills 



CA 02271212 1999-05-07 
42 

before the other. The bill mix applet is preferably operable to control the bill 
mix in accordance with the desires of the institution operating the ATM 
machine as well as is in accordance with the ATM machine's capabilities. 
Alternatively, a JAVA applet for controlling bill mix may reside in device 

5 program 70 in device interfacing software portion 64. 

As will be appreciated by those skilled in the art, the particular JAVA 
applets and/or configuration data in the machine may be selectively loaded 
from the home server 90 at machine start up or at other times. Because the 
applets and configuration data may be selectively delivered to particular 

1 0 machines, the machines may be tailored specifically to the particular ATMs 
currency dispensing and other capabilities. For example, the ATM may be 
configured so that certain applets or groups of applets must be present to 
enable the machine to operate. One approach to loading such data or 
programs is to provide address values in the terminal software to indicate 

15 where the needed instructions to acquire the applets or data may be obtained. 
If the applets or groups of applets are not already present in memory of the 
ATM terminal at start up, the software is operative to access the system 
addresses for the documents which contain the required records or instructions 
which will cause the machine to load the required records. The browser may 

20 be used to access the addresses and the software loads data corresponding to 
the instructions from the accessed documents into a memory in the ATM 
terminal so that the terminal has the required applets and data. Such document 
addresses may be accessible through the home server 90. Alternatively the 
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addresses may be on a separate development server connected to the intranet 
16. In this way each transaction machine is able to load the applets and data 
which include the operative code it needs to operate the transaction devices in 
the machine. Alternatively, the documents may be provided through a 

5 development server or other server that is accessible to the machine through a 
wide area network. The documents may be provided on the development 
server to provide the machine with instructions on how to acquire the 
operating code to carry out a wide variety of functions. The instructions may 
direct the machine to acquire the necessary data and code from addresses 

10 accessible through HTTP servers by an HTTP client in the machine. The data 
and code can be acquired responsive to instructions in one or several 
documents. The machine may also require that the applets loaded in this 
manner be signed applets including digital signatures or other authenticating 
features to achieve operation of certain devices in the machines. 

1 5 Alternatively, embodiments of the invention may acquire the necessary 

applets and data from a remote data store. The data store preferably includes 
the data and/or programs that enable the machine to operate as desired or have 
instructions on where the machine may acquire the necessary instructions and 
data for operation. The data may be accessible from a data base server. The 

20 transaction machine addresses a query to the database server. The query 

includes or is accompanied by indicia from the machine which identifies the 
machine. This may be the particular machine such as a machine number, 
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and/or may include indicia representative of the type or functional device 
capabilities of the machine. 

The data store preferably includes records which have the data or 
programs that are to be transmitted to the machine. In response to the query to 

5 the server, the server retrieves records from the data store and responsive 
thereto delivers one or more messages to the HTTP client in the transaction 
machine. This message(s) includes the configuration data or applets to enable 
the machine to operate in the manner desired or may include instructions 
which indicate how the machine is to acquire such programs from servers 

1 0 connected in the system. 

In the example shown the configuration server and data store may 
operate on the same computer as home bank server 90. In other embodiments 
the database server may reside elsewhere-in the networks to which the 
machine is connected. 

1 5 An advantage of the machines and systems which employ such 

features is the flexibility to change the operation and customer interface of the 
machine to respond to changing conditions. This may include a change in a 
transaction function device. Conditions may change so that certain 
transactions are limited or are not available. For example, a machine may 

20 normally accept deposits but its depository is full. In that situation the 

machine may change the documents it accesses to present messages to users 
through its output devices so that the deposit option is no longer offered. This 
can be accomplished by the applets and data loaded into the machine initially, 
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which provide for instructions when such event is sensed. Alternatively, the 
machine programming may be modified hy loading new applets and/or data 
from an HTTP server responsive to its then current status. This may be done 
responsive to a query to a database server which includes or is accompanied 

5 by data representative of the changed conditions or capabilities of the 

machine. In response the server delivers the applet(s), data and/or instructions 
which will operate the machine in the modified mode. 

This approach eliminates the situation with conventional transaction 
machines where the static interface presentation on output devices offers a 

1 0 transaction option to a customer. Sometimes, after the customer has made the 
selection an indication is given that the selected transactions option is not 
available. The approach described herein may be used with numerous 
transaction options and variations of transactions. The transaction options can 
be readily changed from the database server on a machine by machine basis or 

1 5 even a customer by customer basis as previously discussed, based on the 
desires of the entity operating the transaction machine. 

The discussion of the exemplary transaction will now be continued. In 
response to the cash dispenser 42 dispensing the requested amount of cash, 
device interfacing software program 64 preferably operates to send a dispense 

20 operation message confirming the dispense back to the JAVA applet 
responsible for the dispense in the device application program 84. As 
represented in Figure 12, the particular applet is operative to update the 
transaction record 104 to indicate the dispense of currency to the customer in 
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the particular amount. The embedded JAVA script instructions which were 
operative to cause the dispense of currency to the customer, also preferably 
include instructions to send a confirming message back to the home server 90 
that the dispense is complete. The receipt of the dispense operation message 
5 indicating the cash was dispensed causes the JAVA applet to configure the 

HTML document handling portion to send a device response message back to 
the home server. The home server then is preferably operated in accordance 
with its programming to indicate to the back office 94 that the customer 
received the amount of funds dispensed. This amount is deducted from the 
1 0 customer's account in the records maintained by the back office system. 

Generally during a transaction it is common to ask the customer if they 
wish to have a receipt for the transaction. This may be done at various times 
during the transaction flow. In the present example, after the cash has been 
dispensed the customer operating the machine is sent such a message as 
1 5 reflected in Figure 13. The home server 90 is operative to send an HTML 
document which includes a screen asking the customer if they would like a 
receipt. This message is displayed as part of a page on the touch screen 30 
responsive to receipt of the message through the browser 76. Alternatively the 
document may be generated by the machine. In response to the customer 
20 indicating that they do or do not want a receipt, a message is returned to the 
home server. Again it should be understood that the screens displayed to the 
customer are preferably those that the customer is accustomed to from his or 
her home institution, and may be a part of his or her unique home page. 
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Assuming lhal the customer wishes to receive a transaction receipt, the 
home server 90 operates as shown in Figure 14 to send a document back to the 
ATM with embedded JAVA script indicating that a transaction receipt is to he 
printed. These instructions in JAVA script are communicated to the device 
5 application portion 84 which sends a TCP/IP message through the intranet to 

the device server 92. The device server 92 in turn communicates a message 
with instructions to the device interfacing software portion 64 in the ATM. In 
response to receiving the message, software portion 64 is operative to cause 
the printer 46 to print the customer's transaction receipt. The JAVA applet 
1 0 responsible for enabling the printer is also preferably operative to update the 
transaction data object or record 104. As later discussed, the applet which 
controls the printing of the receipt may obtain the data used in printing the 
receipt from the transaction data object. 

It should be understood that even if the customer does not wish to have 
1 5 a receipt it is desirable to print a record of the transaction in hard copy through 

the journal printer 48. This may be accomplished in response to imbedded 
instructions which are part of the same document from the home server 90 
which causes the transaction receipt for the customer to be printed, or may be 
part of a separate document which indicates that the customer has declined the 
20 option to receive a transaction receipt. Alternatively, the journal printer may 
be actuated responsive to other applets such as the applet which causes the 
dispense of cash, or in another manner chosen by the operator of the ATM. As 
will be appreciated from the foregoing description the operation of the 
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preferred embodiment of the ATM is inherently flexible and programmable to 
meet the needs of the system operator. 

As shown in Figure 15 upon completion of the printing of the 
transaction receipt, the software portion 64 is preferably operative to send a 
5 device operation message to the device server 92 which is indicative that the 

requested device function was earned out successfully. The device server 92 
is operative to send a corresponding device operation message to the device 
application portion 84, and in the preferred embodiment to the particular 
JAVA applet responsible for the printing of the receipt. The JAVA applet in 
10 turn configures the HTML document handling portion to generate a message 
back to the home server in the form of a device response message to indicate 
that the receipt was printed for the customer. 

Having received cash and a receipt, the customer is then prompted by a 
display screen generated from an HTML document from the home server 90, 
1 5 to indicate whether they wish to conduct another transaction. The visual page 

or screen prompting the customer in this regard is displayed on the touch 
screen 30. For purposes of this example it will be assumed that the customer 
does not want another transaction and a message to that effect is returned 
through the HTML document handling portion back to the home server 90. 
20 As shown schematically in Figure 1 7 in response to receiving a 

message that the customer is done, the home server 90 is operative to send a 
"go home" message to the ATM. This message preferably includes an HTML 
document which produces a screen display thanking the customer. This 
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message also preferably includes embedded JAVA script which calls Ihe 
JAVA applet which eventually returns the HTML document handling portion 
of the ATM back into connection with the URL address on the home server 90 
or other address which provides the documents that arc used to output the 
messages for the so called "attract mode". It should be remembered that the 
script in some embodiments may operate to cause a message to be sent from 
the document handling portion to an address on the home server which causes 
a corresponding HTTP record including the instructions comprising the 
desired applet to load. 

As schematically indicated in Figure 18, the "go home" command 
applet is operative to configure the browser 76. After the HTML document 
handling portion is configured by the JAVA applet to return home, the JAVA 
applet may be configured to deliver to home server 90 information from the 
transaction record 104 concerning the transaction that was just completed. 
Because the exemplary transaction was with a customer of the institution that 
operates the computer system 14, all the data concerning that transaction 
should already be recorded in the back office 94. However it will be 
appreciated that this will not be the case if the transaction was conducted in 
response to messages from a server operated by a different institution. Thus, 
all or a portion of the information from the transaction record 104 may be 
delivered in response to a "go home" command to the home server 90 and 
through the CGI to the back office system 94 where it can be identified as 
duplicate information and discarded. This may be done using remote method 
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invocation (RMI) lo pass or deliver the object to server 90 and then 
transmitting the data through messages from the server to the back office or 
through messages or oilier techniques. 

Of course in other embodiments transaction information may be stored 
5 in a database for extended periods rather than being relumed after each 

transaction. Alternatively the ATM 12 of the present invention may include 
applets which are operable to deliver transaction record information to 
addresses other than that of the home server, if that is desired by the operator 
of system 14. 

10 The operation of the computer system when a "foreign" user uses the 

ATM 12 is graphically represented with regard to Figures 19 through 24. A 
transaction with a foreign user who is not a customer of the institution that 
operates ATM 12 and computer system 14, will be operated under the control 
of the home server 90 and will proceed in the manner of the prior example 

1 5 through the point where the customer inputs their card. The customer inputs a 
card having indicia corresponding to a URL address that does not correspond 
to the home server 90. The HTML document handling portion is operative to 
configure a message addressed to access a URL address that corresponds to 
the indicia on the customer's card or other address responsive to such indicia. 

20 This message is delivered to the proxy server 88 which in turn passes the 

message to the wide area network 1 8. From the wide area network the 
message proceeds to the foreign server corresponding to the customer's URL 
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address. For purposes of lliis example the foreign server corresponds lo server 
% which is connected to the Internet. 

In the preferred embodiment of the invention proxy server 88 includes 
screening software graphically indicated 107. Screening software is preferably 
operable lo check addresses to which messages arc being directed by the ATM 
and to selectively prevent the sending of messages lo particular addresses. 
This serves as a "fire wall" and is desirable for purposes of preventing fraud in 
the system. 

As shown in Figure 20, the foreign server 96 is preferably operable to 
communicate HTTP messages, including HTML documents, to the ATM 12 
back through the wide area network 18. This may be done using a secure 
socket connection ("SSC") so as to minimize the risk of interception of the 
messages. Of course other techniques, including encryption message 
techniques may be used to minimize the risk of interception of the messages. 

As schematically represented in Figure 20 the response document from 
foreign server 96 preferably includes embedded JAVA script is representative 
of or corresponds to a digital signature which identifies the foreign server 96. 
This may be accomplished by loading an HTTP record including a signed 
applet, as previously discussed. An applet in application portion 84 in the 
ATM preferably operates to verify the digital signature in the manner 
described in the prior example, and sends a message indicating that the 
transaction has been authorized. The digital identity of the foreign institution 
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will be stored in memory in the ATM and eventually recorded in the back 
office 94. 

It should be noted that the HTML documents from the foreign server 
96 produce the visual pages or screens of the foreign institution which the 
5 foreign customer is accustomed to seeing. These pages may correspond to the 

foreign user's "home page" which are tailored specifically to the needs of the 
particular user. 

Figure 21 shows an example of a document accessed through the 
foreign server 96 to the ATM 12. The document from the foreign server may 

1 0 include embedded JAVA script which enables operation of the JAVA applets 
in the manner previously discussed to operate the devices 36 in the ATM. As 
shown in Figure 21 the TCP/IP messages to the devices from the JAVA 
applets pass from the device application portion 84 to the device server 92, 
and the instructions therefrom to the device interfacing software portion 64 in 

15 the ATM. Device operation messages take a reverse path. As these messages 
pass through the device server 92, monitor software 102 monitors them to 
minimize the risk of fraud or abuse. 

As indicated in Figure 21 , the documents from the foreign server 96 
may be operative to display at the touch screen 30 a request for the customer 

20 to input their PIN. The embedded JAVA script instructions would, as in the 
sample transaction previously discussed, include instructions that enable the 
keyboard 40 to accept the customer's PIN. As in the prior example, a 
transaction record 104 which includes a shared data object concerning this 
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transaction would be opened by the device application software portion. As 
previously discussed, provisions may be made to prevent the passage of PIN 
data through the browser if desired. 

Figure 22 indicates the return of the device operation message and PIN 

5 data to the JAVA applet, which in turn transmits the data back to the foreign 
server 96 through the wide area network 18 using the secure socket 
connection. From this point the transaction proceeds generally as previously 
described, except that the foreign server 96 sends the HTTP records, including 
HTML documents, and receives the messages from the document handling 

10 portion of the ATM. The foreign server 96 includes the JAVA application 
software necessary to include the embedded JAVA script in the documents 
that are sent to the ATM to operate the devices 36 in the machine. 

As the foreign server 96 operates the machine, the monitor software 
102 in the device server 92 is operative to monitor the messages in the manner 

1 5 previously discussed. Such monitoring would for example, operate to prevent 

the dispense of unduly large amounts of currency out of the machine. The 
monitoring software may also operate to restrict certain foreign institutions to 
a subset of the transaction machine devices or capabilities. This is done based 
on data stored in memory which limits the devices or activities that can be 

20 carried out from documents at certain addresses. This may be achieved for 
example through the use of code plug-ins which implement a class of the 
transaction objects which limits the operations that can be performed. For 
example, the operations which enable connection to the foreign server may 
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instantiate the objects which provide specified limited capabilities for 
messages received from the foreign server. This may for example limit the 
amount of money dispensed, prevent operation of a check acceptance device, 
limit the dispense to printed documents such as tickets, prevent operation of 

5 the cash dispenser or limit use of the machine in other appropriate ways. This 
may be done based on the addresses or portions of addresses for documents. 

If the capabilities of the machine to the foreign customer are limited, 
the foreign customer may be provided with a visual interface from the foreign 
bank based on the transactions the machine can perform and that the owner of 

10 the machine will allow. As a result the documents accessed at the foreign 
bank server may be a variation of what the customer would be provided at a 
machine operated by the foreign bank. This could be based on documents 
specifically developed for operating foreign machines, or could be a variant of 
the usual foreign bank interface with visual indications that certain 

1 5 transactions are not available. In some instances the interface may indicate 
that some transactions are available with an associated service charge. 

The ATM of the described embodiment may enhance security by 
limiting the addresses that the browser may access. This may be done by 
maintaining a list in the memory of the machine. This list may be maintained 

20 in HTTP record(s) (including documents) accessible through the home bank's 
intranet. The machine may access the record periodically and update the 
memory data. This record may itself require a digital signature corresponding 
to a signature in the terminal memory before the data will be loaded into 



CA 02271212 1999-05-07 
55 

terminal memory. This information may also include the instructions and 
information for the ATM to verify that the messages it receives by accessing 
documents on the foreign server are genuine. This may include digital 
signatures which when transferred using public key or private key encryption 

5 techniques verify the messages as genuine. The machine checks to be sure the 
signature in the records accessed from the foreign server corresponds to the 
digital signature for that address stored in memory, and enables operation of 
transaction devices, such as the cash dispenser, only when such 
correspondence is present. Of course various approaches to verifying and 

10 encrypting messages may be used in various embodiments. As used herein 
signatures or signed record encompass any indicia which is included in or is 
derivable from a record which is indicative that it is authorized. 

As can also be appreciated from the foregoing disclosure, the foreign 
server 96 may communicate to the user through the touch screen in a language 

1 5 that is different from that normally used by the customers of the institution 

that operates the computer system 14. As a result the HTML documents may 
display requests to dispense currency of a type or in an amount which is not 
included in the ATM. To accommodate this situation an applet is preferably 
included in the device application portion 84 to deal with requests for foreign 

20 currency. The foreign currency applet causes the ATM to send a message 
back to its home server for purposes of calculating a closest amount which 
may be provided to the customer in the available currency in the ATM which 
corresponds to what the customer requested. As will be appreciated, this 
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applet will be operative to call the particular function address within the home 
server 90 that is capable of providing this function. When the dispense is 
made the applet is also operative to indicate to server 96 that the amount 
dispensed differs somewhat from the amount the customer requested. Of 
5 course in other embodiments, other approaches may be used. Alternatively an 

applet in the machine may generate visual displays that show equivalents in 
local currency when foreign currency amounts are displayed or processed. 
This may include presenting both amounts on visual displays presented to a 
user. 

1 0 As represented in Figure 23, when the foreign customer has completed 

their transactions as indicated through the touch screen 30, the foreign server 
96 is operative to send the "go home" message back to the ATM. The receipt 
of this message is operative in the manner previously described to cause the 
device application portion 84 to operate responsive to the embedded JAVA 

15 script instructions to configure the HTML document handling portion to cause 
the browser 76 to reestablish communication with the home server 90, or other 
designated document address. 

As indicated in Figure 24 the applet in the device application portion 
84 which processes the "go home" message is preferably operative to 

20 reconnect to the home server 90 as well as to send the transaction record 
information in record 104. This transaction record information which is 
preferably packaged in a data object, includes the customer name, the foreign 
institution name, digital identifier, amount information concerning amounts 
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dispensed, transferred or deposited, and all other pertinent transaction data. 
The transaction data is used by applets in performing transaction steps in 
which any portion of the data is required. At the completion of the customer's 
activity at the machine an applet provides a transaction data message which 

5 includes at least a portion of the collected data. This data is communicated 

from server 90 through the CGI 106 to the home bank's back office 94. This 
information is stored in the back office for later use for purposes of settlement 
with the foreign bank operating the foreign server 96. Alternatively or in 
addition, transaction data may be recorded in the terminal in memory as well 

10 as in hard copy on a journal printer. Transaction data may be stored for 
downloading in a batch or by passing objects including data from many 
transactions. Batch data may be communicated at times and to addresses as 
may be stored in memory in the terminal configuration data. 

An advantage of embodiments of the invention is that transaction data 

1 5 may be delivered to addresses in a local area network or in a wide area 

network such as the Internet. This facilitates conducting wide varieties of 
transactions and enables directing messages related to tracking use (such as for 
electronic purse type smart cards) or for settlement of various transaction types 
to a selected system address. 

20 It will be appreciated that the described embodiment of the automated 

banking machine and system of the present invention provides the advantage 
that when the machine is connected to a wide area network such as the 
Internet, customers are able to carry out their banking transactions virtually 
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anywhere in Ihe world. Further, despite Ihe broad capabilities of the system, 
because the machine may be monitored locally, both in terms of connection 
and activity, the risk of fraud is minimized. 

Embodiments of the invention may include a further feature to 

5 facilitate access to documents in the network to which the machine is 

connected. This feature is operative to determine if an HTTP record such as 
an HTML document or other item is accessible at an address for downloading 
before the computer will attempt to access the record. This avoids transaction 
time outs that might otherwise occur as a result of inability to access a record 

10 due to the server through which the record is normally accessed being down. 

Other embodiments may consider both the size of the record and the transfer 
rate and determine that a transfer speed for the record is not sufficiently rapid, 
so that an alternative record should be transferred. 

In one embodiment this feature is achieved through use of a separate 

1 5 program or applet which checks to see if a server that the computer will 
subsequently want to access is alive. The applet operates responsive to 
receiving an address or portion thereof, to which a connection will be made. 
The applet operates to make a socket connection to the address and loads a 
small but sufficient amount of the record or otherwise operates to determine 

20 that the server through which the record must be accessed is alive. In response 
to the applet verifying the operation of the remote server, or otherwise 
determining that conditions indicative that the record may be accessed or 
loaded, the computer then operates so that the browser or similar software 
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component is enabled lo navigate to the address at the appropriate time in the 
transaction sequence. If the applet is unable to detect that the remote server is 
alive, or determines that it docs not appear the record may be successfully 
accessed or loaded, steps may be taken to access alternative addresses or lo 

5 discontinue the transaction. Alternative addresses to access may be based on 

data stored in the memory ofthe terminal or may be obtained by accessing 
documents either locally or remotely which include data from which 
alternative addresses may be obtained or derived. Alternative addresses are 
similarly checked to make a determination that the records can be accessed 

1 0 before attempts are made to access the alternative records. This approach 
avoids delays in carrying out transactions. 

Alternative embodiments may employ other approaches to determine if 
desired HTTP records such as HTML documents may be successfully 
accessed and/or downloaded adequately before the browser providing the 

1 5 customer interface attempts to access the document. Such embodiments may 
consider in determining whether the document can be successfully accessed, 
the transfer speed or other conditions related to system operation or document 
content. For example, the applet which tests to determine that the HTTP 
record can be accessed, or a further applet, may determine the transfer rate at 

20 which the record can be transferred to the computer. The rate at which the 

data can be transferred may be compared to data stored in memory, and if the 
rate is slower than the data representative of the desired stored rate an 
alternative record is accessed. This may be for example an HTML document 
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stored locally in the machine. Other embodiments may include programs 
which consider the size of the HTTP record and the transfer rate in 
determining a transfer speed. Such programs then determine if the record can 
be transferred fast enough to suit the parameters established in the 
configuration in memory, and if not, alternative addresses are accessed. Such 
alternative records may be similarly tested for transfer speed before being 
transferred. 

Programs may also consider other factors in deciding to access a 
particular address, such factors may include for example day and time 
information, or information from sensors such as sensors in a floor indicating 
that other persons are waiting to use the machine. In this way access to 
documents that have extensive outputs which may tend to prolong transactions 
can be avoided even when records can be loaded at an adequate speed. 

While the described embodiment of the automated banking machine 
and system of the present invention is shown with regard to a particular type 
of machine that is made specifically for connectibility to local or wide area 
networks, conventional automated banking machines may also be adapted to 
include such capability. Specifically the HTML document handling portion 
and device application portions may be included with other conventional 
software which operates within an automated banking machine. This enables 
such ATMs to operate either in the conventional proprietary network or as part 
of a wide area network. In addition, automated banking machines may be 
configured to operate their devices through the device interfacing software 
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portion of the invention or through a different software interface when 
operating in a conventional network. Such machines may switch to requiring 
device messages to be passed through a device server when operating under 
the control of a server within the wide area network to maintain security 
within the system. In this way a single ATM could operate in proprietary 
networks in the manner of current ATMs as well as in the network 
configuration of the system of the invention. 

Alternative embodiments of the invention operate to communicate 
transaction messages used in a proprietary ATM network. This may be 
accomplished by using a CGI in connection with either the HTML document 
handling portion of the ATM or the HTTP home server or other server. The 
CGI operates in connection with a message conversion program and database 
to cull the necessary data from the HTML documents and response messages 
and generate the defined transaction request messages appropriate for the 
proprietary transaction network. Likewise, the message conversion program 
and CGI operate to receive function command messages from the proprietary 
network and convert them and generate appropriate HTML documents and/or 
TCP/IP messages for use by the ATM. Because these proprietary network 
formats are defined and the data necessary to produce and interpret the 
messages are known, the use of the ATM 12 directly in a conventional 
proprietary ATM network is achieved. 

Conventional ATM transaction messages are defined layout messages 
that do not include HTML documents on HTTP messages. An example of 
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known conventional messages used to operate ATMs are Diebold 91 X 
messages. Such messages generally involve transmission of a request 
message from an ATM in a defined layout including customer input data 
(account/pin) and an indication of the type and amount of transaction 

5 requested. The request message is received by an ATM host computer which 
sends back a response message with a defined layout which includes an 
indication whether the transaction is authorized. The ATM then returns 
another message to the host computer indicating whether the machine was able 
to carry out the transaction. The messages used in such conventional 

1 0 proprietary networks generally occupy relatively little band width. 

In connecting the ATM of the invention to such a network, a server is 
provided. The server is in operative connection with a memory which 
includes a relational database which holds the message conversion and 
document creation data. In one configuration, the server is connected to the 

1 5 document handling portion through a network, or may reside on the computer 
of the ATM. The server produces the documents which the browser accesses 
and which include the transaction device instructions. The server (or a 
connected server) communicates the conventional messages with the host. 
One server may provide an interface for several ATMs connected to it in a 

20 LAN, or alternatively, each ATM may have its own server operating therein. 

The ability of ATM 12 to communicate in a proprietary network also 
enables operation of the ATM in a manner in which the interface is generated 
by a user's home institution in the manner previously described, but in which 
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transactions are authorized through messages directed through a proprietary 
ATM network. This achieves the security of using the proprietary network 
while providing the customer with the advantages of the familiar home bank 
interface and/or "personal home page" interface. 

In such a configuration the ATM transaction junction devices may be 
operated in a conventional manner in response to conventional ATM 
transaction messages such as Diebold 91X messages, in the proprietary 
network. The customer output devices, such as the screen (and speakers if 
provided) communicate through a browser connected to a local or wide area 
network. The browser accesses documents to prompt a customer through 
operation of a transaction, but the documents do not include instructions which 
cause operation of devices such as the cash dispenser. 

In one configuration the browser may be operated by the computer in 
response to the status of devices in the machine, as the devices are operated in 
response to conventional ATM messages. In this manner the browser may be 
navigated to selected addresses, including addresses which are associated with 
the customer based on customer input data. However, as the documents 
received by the browser will not operate the transaction function devices, there 
is less need for security measures in accessing documents. As a result, the 
customer may still operate the machine in response to a familiar and unique 
interface, and marketing information such as advertising or other material may 
be presented in the transaction sequence. 
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In other embodiments machines may perform some device functions 
based on conventional messages, while others may be performed in response 
to instructions in HTML documents or other HTTP messages. For example 
HTML documents may provide considerable data for use by printers or other 
output devices. Some embodiments may access documents with instructions, 
but may ignore some and act in response to others. The approach may be 
selected by the systems operator by configuring the software based on their 
requirements. 

A further advantage of the system configuration of one preferred 
embodiment is that it has enhanced flexibility for communicating messages 
associated with the ATM. The device manager 68 preferably generates status 
messages associated with the status of devices 36. These status messages may 
commonly represent information about conditions which exist at the devices. 
Such messages may indicate that supplies of paper for printers or currency, are 
low or are depleted. Other messages may indicate that devices are not 
functioning properly. Often such messages indicate that the ATM requires 
servicing. All such types of messages are referred to herein interchangeably as 
status or fault messages. 

The device interfacing software portion 64 communicates through the 
intranet 16 using TCP/IP messages. While the messages associated with 
transactions previously described are directed to the device server 92, the 
software portion 64 may include a server and be configured to address fault 
and status messages to other addresses in the intranet or the Internet. For 
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' example, such fault or status messages may be directed to a software 
application which delivers messages to a service provider. Further, fault 
messages may be selectively directed based on the nature of the fault 
indicated. For example, fault messages indicative of a need to replenish 
5 currency or supplies may be directed to an address in the intranet associated 
with an entity who has responsibility for replenishing supplies. Alternatively, 
fault messages which indicate a need for other types of servicing may be 
directed to an address associated with an entity who can provide the type of 
servicing required. 

1 0 Alternatively, the selective dispatching of fault messages to addresses 

in the intranet 16 may be accomplished by appropriately configuring device 
server 92. In addition, either software portion 64 or device server 92 may 
direct fault messages from the ATMs to a fault handling system such as to a 
computer operating Event Management System™ software available from 

1 5 Diebold, Incorporated. Such software is operative to resolve the nature of the 
fault condition and to notify appropriate personnel of the corrective action to 
be taken. 

The ATM 12 may further include a software function to assist in 
diagnosing problems and providing remedial service. As graphically 
20 represented in Figure 2, alternative embodiments of the ATM 12 may include 
a mini-HTTP server 109 which is in communication with the device 
interfacing software portion 64. Server 109 is configured to receive device 
status messages and to produce HTTP records including HTML documents in 
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response thereto, which provide data representative of device status to a 
diagnostic device 110 such as a hand held computer terminal. Server 109 
includes a CGI for interfacing with the device software so that a technician 
may access the information in the records accessible at the HTTP addresses 
5 related to status messages and input test and corrective instructions through 

diagnostic device 110. The HTTP records and/or HTML documents generated 
by server 109 may preferably include graphic and audio instructions indicative 
of conditions such as problems, as well as corrective action data and repair 
instructions. 

10 In alternative versions of the invention the functions of the mini-HTTP 

server 1 09 may reside in device server 92. This may be particularly 
appropriate where the function of the device server resides on the computer in 
the ATM. Regardless of where the function resides the use of the visual and 
audio components of HTML documents associated with maintenance and 

1 5 diagnostic messages facilitates servicing of the ATM. 

These records delivered through the mini-HTTP server include 
instructions that correspond to the status or fault conditions. Such records or 
documents may be accessed locally as previously discussed, or remotely. A 
technician using a hand held computer which includes a browser or other 

20 software operative to access the HTTP records may access the documents 
locally for purposes of maintenance, diagnosis and servicing. In some 
situations the customer interface and browser associated therewith may be 
used to access the mini-HTTP server, of a separate browser, display and input 
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devices on the machine and intended for use servicing activity may be used. 
Alternatively, the fault and status messages may be monitored from terminals 
at locations anywhere that are connected in the network. The mini-HTTP 
server handling status and fault messages may also be configured to send an e- 
5 mail or similar message to a selected address whenever a particular condition 
or group of conditions exist. 

A further advantage of this feature is that HTTP messages may also be 
sent to the mini-HTTP server to attempt to correct problems. Such messages 
may include running diagnostic tests and receiving results. It may also include 

10 operating devices to test or attempt to clear jams and other malfunctions. This 
can often be done from remote locations. Of course, when there is a 
significant risk of unauthorized access to the server handling default or device 
messages, appropriate security measures should be taken. 

The HTTP records which indicate the status of the transaction function 

1 5 devices may have different forms depending on the software configuration and 
the needs of the system operator. In some embodiments the device status 
information for one or more devices may be represented by indicia contained 
within a data object. The data object may be transferred to other connected 
computers to provide the status data. The transfer of the data object may be 

20 accomplished by remote method invocation (RMI) for example. The data in 
the transferred data object may then be used to generate message and/or 
outputs desired by the system operator. This technique may be particularly 
useful when the operator wishes to connect the machine to an existing 
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monitoring system and indicia included in the data object can be used to 
generate outputs or messages indicative of device status that can be processed 
by the existing system. Plug-ins may further be used to achieve 
communication between existing monitoring systems and transaction 
5 machines which have different types of status conditions or different types of 

message formats. This includes machines which have different types of 
transaction function devices and capabilities. 

The technique of transferring a data object may also be used to conduct 
testing or modification of transaction function devices. For example, indicia 
1 0 in the data object may be modified by a servicer and the object passed back to 
the machine. The software in the machine may cause the transaction function 
devices to operate or change conditions or programming in response to the 
modified data object. This may include for example clearing a fault indication 
or causing a device to operate to clear a jam or to conduct a test. The results 
1 5 of such activity may be reflected in modified indicia in the data object which 
may then be transferred to the computer in the diagnostic terminal. Of course, 
the approaches discussed herein are exemplary and other approaches will 
become apparent to those skilled in the art from the description herein. 

Figure 25 shows a schematic view of a network configuration for an 
20 alternative embodiment of the automated banking machine of the present 
invention. The embodiment shown in Figure 25 includes an automated 
banking machine specifically adapted for operating in connection with 
conventional automated banking machine systems such as systems which 
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operate using Diebold 91 X ATM message formats or other non-HTTP 
conventional format. A host computer 120 is a conventional ATM host which 
communicates using such messages. The host communicates with an interface 
server schematically indicated 122, Interface server 122 operates in the 

5 manner previously discussed and is in operative connection with a memory 

that includes the information necessary to convert HTTP messages that pertain 
to a transaction request to a 91 X request message or other conventional 
message, which can be handled by host computer 120. Likewise interface 
server 122 and the instructions and data stored in memory are operative to 

1 0 convert a conventional 91 X command message or other conventional 

command message from the host 120 into HTTP messages which can be used 
by the automated banking machine to carry out the command. Similarly 
interface server 122 is operative to receive the HTTP messages which 
correspond to the response of the automated banking machine to the 

1 5 commands and to produce a 91 X response message or other conventional 

response message to the host. In accomplishing these functions the interface 
server communicates with a interface client 124 which in the preferred 
embodiment is a COMM plug in which operates on the banking machine 
terminal under a Windows NT® operating environment. Interface server 122 

20 also includes a command/status gateway 126. The command/status gateway is 
operative to receive command and status messages from the software portions 
handling the functional devices within the machine. The messages concerning 
the devices are used in producing transaction messages to send back to host 
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1 20. In addition, the command status gateway portion also produces status 
messages indicative of the status ofdeviecs which may also be communicated 
to (he host. 

The interface server 122, command status gateway portion 126 and 

5 interface client 124 may reside in software on the automated banking machine 
terminal. In this configuration the terminal appears to the host computer to be 
a conventional machine. Alternatively interface server 122 and command 
status gateway portion 126 may reside on a separate server, while the interface 
client portion 1 24 may reside on the terminal. This enables the interface 

10 server 122 to handle a number of automated banking machines by connecting 
the machines to the interface server through a network. 

The alternative configuration of the automated banking machine 
system shown in Figure 25 is particularly adapted for use in connection with 
existing ATM system. The machine includes an HTML document handling 

1 5 portion 1 28 which includes a browser which operates in the manner of the 

embodiments previously described. The HTML document handling portion is 
alternatively referred to as a browser herein for purposes of simplicity. The 
HTML document handling portion operates in connection with a network 130 
to access HTTP records in the form of HTML documents through servers 132, 

20 134 and 136. For purposes of this example server 132 will be considered the 
server of the home bank which operates the automated banking machine. The 
browser portion 128 is enabled to access documents of its home bank for 
purposes of obtaining content and instructions for purposes of outputting 



CA 02271212 199905-07 



71 

' information to customers as well as for operating devices on the machine. 
Servers 134 and 136 are representative of other servers which the automated 
banking machine may be instructed to access for purposes of downloading 
documents which include information or instructions. Often such documents 
from non-home bank servers will include information which is to be presented 
to customers such as advertising, promotional material, stock quotations or 
other types of information. It should be understood that the servers 134 and 
1 36 may be directly connected to network 1 30 or may be accessed through 
other networks and servers. In some embodiments such servers may be 
accessed through the Internet for purposes of providing documents to the 
automated banking machine. 

Document handling portion 128 includes a terminal theater software 
portion schematically indicated 138. Terminal theater portion 138 is 
schematically shown in greater detail in Figure 26. Terminal theater portion 
138 includes a back stage frame 140 and a theater frame 142. The back stage 
frame 140 although it resides in the browser, is not visible on the screen of the 
. automated banking machine. The theater frame 142 is a visible frame and 
controls what is shown to the customer. 

As schematically represented in Figure 25 the HTML document 
handling portion also includes a terminal director portion 144. The terminal 
director portion includes directors which are related instances of applets which 
are used in carrying out particular types of transactions. The terminal directors 
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generally correspond to the operation of the JAVA applets in the previously 
described embodiment. 

The automated banking machine of the alternative embodiment further 
includes a transaction services application (TSA) schematically indicated 146. 

5 The transaction services application provides security, terminal condition, 
terminal authorization and key management services within the automated 
banking machine. The transaction services application includes a function for 
communicating HTTP messages with the interface server 122. The transaction 
services application may also communicate through a network such as 

10 network 130 in a manner later explained. The transaction services application 
also provides a server function which enables the transaction services 
application to carry out the functions of the device server 92 in the previously 
described embodiment. 

The automated banking machine of the alternative embodiment further 

15 includes JAVA common device interfaces schematically indicated 148. The 
JAVA common device interfaces in the preferred embodiment are related 
instances of applets which control and coordinate the operation of the 
functional devices 150 of the machines which perform transaction functions. 
The functional devices may include devices of the types described in 

20 connection with the previous embodiment or other types of devices which 
operate to carry out a function related to a transaction. The JAVA common 
device interfaces 148 communicate with the functional devices through 
common device interfaces schematically represented 152. The common 
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device interfaces (CDIs) provide an interface thai controls the 
electromechanical modules in the functional devices included in the automated 
hanking machine. The common device interfaces are schematically shown in 
connection with a diagnostic server 154. The diagnostic server operates in a 

5 manner similar to server 109 of the previously described embodiment. The 

diagnostic server 154 is useful in diagnosing status and in correcting problems 
with the devices in the automated banking machine. 

Referring again to Figure 26 the backstage frame 140 within the 
terminal theater portion 138 is a component called the backstage applet 156. 

1 0 The backstage applet 1 56 is preferably a relatively thin component. 

Instructions referred to as script included in documents accessed by the 
browser selectively cause the backstage applet to notify a terminal director 
when an action is to take place in response to the instructions included in the 
accessed document. The backstage applet also operates to request that a new 

1 5 HTML document be accessed. The backstage applet also provides access to 
the shared transaction data object previously discussed which holds 
transaction data. 

The theater frame 142 controls the user interface as seen by the user of 
the automated banking machine terminal. Client HTML schematically 
20 represented 158 in the theater frame 142 defines the identifying indicia 

associated with events sent to a director manager through the backstage applet 
and provides an interface to the director manager's public methods. The 
director manager schematically indicated 160 in Figure 26, has a class which 
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resides in (he transaction services application (TSA) 146 as shown. The 
director manager class residing in the TSA process is operative to load the 
terminal directors 144 to the I ITML document handling portion. The director 
manager also includes a backstage applet class that resides in the backstage 

5 frame 140. The backstage applet class of the director manager provides an 

interface for the client HTML to make requests on the director manager. 
Instructions in HTML documents can pass events through the backstage applet 
1 56 to the director manager. Such events include a request to authorize a 
transaction. Such requests may also include indications that the customer has 

1 0 completed a transaction or that a document loaded by the browser includes 

instructions requesting that the session be terminated. Other events which can 
be passed through the director manager include print events. Other events 
which can be passed through the backstage applet to the director manager 
include an indication that an entry was cancelled, or other defined user events. 

1 5 In response to receiving events the director manager of the 

embodiment shown responds to instructions in documents accessed by the 
browser to perform functions which include changing the content of the 
theater frame 142. The director manager responsive to such instructions, also 
changes the active terminal director class. The director manager also caches 

20 terminal director classes for later use or loads terminal director classes and 

HTML documents from a list of available servers. The director manager also 
provides access to the shared transaction data object holding transaction data 
for a particular transaction. The director manager also sends terminal theater 



CA 02271212 1999-05-07 



75 

events to the backstage control class of the current terminal director and 
provides a screen timeout timer. Of course in other embodiments the terminal 
director may carry out other functions. 

In operation of the alternative embodiment shown in Figure 25 the 
terminal directors 144 in the transaction services application 146 enables 
selectively accessing documents with the HTML document handling portion 
128. The documents accessed may include instructions which are used to 
operate the automated banking machine and the functional devices thereon. 
The transaction services application 146 is further operative to communicate 
the HTTP messages which are passed to the interface server 122 and which are 
used to generate conventional ATM messages which can be handled by the 
host 120. The dispensing of currency and other transfers of value are carried 
out in response to approval from the host 120, while the interface and other 
functions are controlled through instructions in documents accessed through 
the browser. 

In one preferred embodiment the ATM or other transaction machine 
communicates with the conventional ATM host by passing the transaction data 
object between the computer in the ATM and the interface server. This 
transfer is preferably accomplished by the remote message invocation (RMI) 
feature of software such as JAVA. Of course other methods for transferring 
the data object file using HTTP may be used. 

As previously discussed, the transaction data object holds transaction 
data. The machine acquires data pertinent to the transaction such as account 
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dala from a card, a customer's PIN number, requested Iransaction(s) and 
amount(s), and includes this data among the transaction dala. 

Once the dala needed to generate a conventional ATM transaction 
message is represented in the transaction data, the data object is transferred to 
5 the interface server. The interface server is in operative connection with a 

database 123 or other item holding conversion data as schematically indicated. 
The conversion data is used by Ihc software associated with the server to 
generate a conventional ATM transaction request message to the host 120. 
The conventional message may be formatted as a conventional 91 X message 
1 0 or other conventional non-HTTP transaction message. 

After processing the host 120 responds with a conventional response 
message. The components of the response message are received at the server 
and processed responsive to the conversion data to produce modified 
transaction data in the data object. This modified transaction data preferably 
1 5 includes data indicative of whether the requested transaction is authorized or 

denied, as well as other data. For example, if the transaction is denied it may 
include data which is indicative of the reason for the denial. 

The transaction data object with the modified transaction data is then * 
transferred to the computer operating the ATM by RMI or other transfer 
20 method. The transaction services application 146 operating in software 
receives the data object and operates the transaction function devices 
responsive to the modified transaction data. The transaction data object has 
the transaction data therein further modified by the inclusion of information 



CA 02271212 1999-05-07 



77 

concerning operation of the devices. After the devices have operated, the 
transaction data object with the further modified transaction data is passed 
back to the interlace server 122. The modified transaction data is then used to 
generate a message to the ATM host. The message to the host includes data 
corresponding to the modified transaction data. Usually this message is a 
conventional non-HTTP completion message indicating whether the 
transaction was successfully carried out by the transaction function devices. 

The format of the non-HTTP conventional transaction messages may 
be readily changed in the described embodiment. This can be achieved 
through the use of plug-ins. The plug-ins are operative to put data into, and to 
extract data from, the transaction data object. The plug-ins achieves 
conversion between the transaction data and desired conventional non-HTTP 
messages. The use of plug-ins enables more readily using the ATM of the 
described embodiment in connection with varied types of conventional 
transaction networks. 

Transaction data in the transaction data object is also preferably 
operative to have the computer operate the browser to access selected HTML 
documents. This may be done to indicate that the transaction is authorized or 
denied, as well as to access specific documents responsive to components of 
the message. For example, customers of banks other than the one operating 
the ATM may be given certain promotions not presented to the bank's existing 
customers. The transaction data indicative of why a transaction is denied can 
be used to access documents which provide an explanation, or can encourage 
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the customer to hike oilier action, such as to lake a cash advance on a credit 
card or to apply for a loan. 

The system schematically shown in Figure 25 is an example of an 
automated banking machine system that achieves the wide variety of interface 
5 options available through the use of an HTML interface while preserving 
compatibility with existing banking machine systems and the security 
techniques associated therewith. Of course in other embodiments alternative 
approaches and configurations may be used. 

A further advantage incorporated into the system schematically 
1 0 represented in Figure 25 is the ability to operate the software components of 
the described embodiment of the present invention in existing automated 
banking machines. As will be appreciated, the handling of HTML documents 
in conventional computers requires inputs through a QWERTY type keyboard 
as well as mouse clicks in locations corresponding to icons or other features 
1 5 on HTML documents to successfully navigate and use such documents. 

Conventional automated banking machines generally do not include a mouse 
or full keyboard. Rather conventional automated banking machines generally 
include an alphanumeric keypad similar to that used on telephones, as well as 
function keys. Embodiments of the present invention enable the operation of 
20 the system with terminals which have such interfaces operate in a manner 
which attains benefits of the invention. 

Figure 27 shows an example of a conventional automated banking 
machine interface 162. Interface 162 includes an output device which 
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includes a screen 164. Screen 164 may be a CRT, LCD or other conventional 
display screen. In the embodiment shown screen 164 is not a touch screen as 
in the previously described embodiment. A plurality of function keys 166 are 
disposed at locations adjacent lo the screen 164. A keypad 168 is also 
5 included in the interface 162. Keypad 168 includes alphanumeric keys as well 

as certain other dedicated keys such as "cancel", "correct" and "ok". Other 
keys on the keypad are generally blank but in some instances may be used. 

In the operation of a conventional automated banking machine, screen 
data which is generated from information stored in the terminal memory 
1 0 produces defined transaction screens which are presented graphically on the 
screen 164. The screens appear in a sequence in response to the transaction 
function selected by the customer. Conventional screens also generally 
include text or graphics representative of selections that can be made by a 
customer. These text or graphic options generally includes lines or other 
1 5 indicia which extend to the edges of the screen adjacent to one of the function 

keys 166. A user is enabled to select the options by pressing the function key 
which is pointed to by the selection. Likewise in the operation of the 
automated banking machine a user is enabled to input the alphanumeric 
characters which comprise the PIN number as well as numeric amount 
20 information and other instructions by pressing the keys in the keypad 168. 

In one embodiment of the present invention the software operated in 
the automated banking machine operates to convert standard ATM key inputs 
to operating system events such as a mouse click in a desired location or an 
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input from a QWIiKTY type keyboard. The software components which 
enable carrying out this function are shown in Figure 28-30. These functions 
include a keypad applet 170. The keypad applet 170 in the described 
embodiment is included among the applets in the terminal directors 144. The 
5 keypad applet 1 70 supports a subset of the keyboard common device interface 
(CDI) functionality. 

The keypad applet 170 coordinates with a keyboard command server 
which operates in the transaction services application 146. The server in the 
transaction services application communicates with the common device 
10 interface for the keypad and function keys, schematically indicated 172. The 
key CDI in the preferred embodiment is a JAVA program which is referred to 
as a wrapper for the common device interface associated with the function 
keys and the keypad. 

The software further includes a keyboard mapper program 
1 5 schematically indicated 1 74. The keyboard mapper in the preferred 

embodiment is in connection with a database 176 which stores a plurality of 
map sets. In the preferred embodiment the keyboard mapper is an extension 
of the keyboard class of objects used for operating the keyboard. The 
keyboard mapper operates to store sets of keymaps in the database 176. This 
20 is accomplished by reading information in a configuration database for the 
ATM to obtain the keymaps that are operated in the particular machine. 
During operation, the keyboard mapper selects one of the keymaps as the 
current set. This is done in response to the keypad applet and is based on 
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instructions in I ITTP records which arc selectively accessed. The keyboard 
mapper may select keymaps responsive lo instructions in HTML documents 
' loaded through the browser. The keyboard mapper is also operative to enable 
the keypad and function keys appropriate for the particular mapsel selected. 
5 The keyboard mapper is further operative responsive to the selected mapsel to 
translate a keypad input signal or a function key input signal into a respective 
keyboard or mouse input signal which is then delivered to the keyboard input 
stream or the mouse input stream of the operating system of the computer in 
which the software operates. 

1 0 In the preferred embodiment the mapsets are each comprised of hash 

tables. Keymap objects are stored as values in the hash tables such that each 
object includes the values and operations necessary to convert any appropriate 
ATM key event to an operating system input event. 

As can be appreciated in the case of function keys adjacent to the ATM 

1 5 screen it may be desirable to provide a mouse input to the mouse input stream 
that corresponds to a particular coordinate location for the mouse input. This 
is provided by the keyboard mapper using the selected keymap set. The 
various keymap sets enable the different function keys to provide different 
types of inputs to the computer operating system responsive to the HTML 

20 document displayed on the browser. Further the keyboard mapper causes the 
pressing of a selected key to produce an input corresponding to a mouse click 
at a selected x,y coordinate position on the screen. It should be understood 
that either keypad keys or function keys can be used to produce mouse inputs. 
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Likewise function key inputs may be converted to keyboard inputs. In some 
embodiments however it will be desirable to disable the mouse indicator on 
the screen such that the user does not notice a usual mouse icon. Such 
disabling may include in some embodiments reducing the size of the mouse 
5 icon such that it is so small that it cannot be readily seen by a user of the 
machine. 

During portions of some transactions it may be unnecessary for the 
user to press any keys. In such situations some preferred embodiments of the 
invention operate to disable the keypad keys and/or function keys. Because 

10 resources of the computer are used in polling such keys for inputs, the 
cessation of such polling during appropriate times enables the computer 
resources to be devoted to carrying out other functions. This will increase the 
speed at which other activities may be carried out. This may be accomplished 
in some embodiments by the keypad applet operating to remove the key 

1 5 devices from a poll list. 

Figures 28-30 include schematic depictions of examples of the 
operation of the keyboard mapper and the keypad applet. Figure 29 shows an 
example of an input to the keypad 168. In this example the keypad applet 170 
generally in response to instructions in an HTTP record such as an HTML 

20 document or other events, transmits and enables events to the transaction 

services application 146. In response a mapset is selected from the database 
176 corresponding to the particular map name. The keyboard command server 
is further operative to enable the appropriate keys of the ATM. 
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In this example, in response the customer pressing the "OK" key on 
the keypad the CDI generates an appropriate signal to the transaction services 
application. As will be noted from Figure 27 a "OK" key is referred to by 
convention as the "J" key of the ATM interface. The transaction services 

5 application transmits the signal generated from the pressing of the "J" key by 
the customer to the keyboard mapper 174. In response to receiving the signal, 
the keyboard mapper operates to resolve the object in the mapset 
corresponding to the map name which will convert the function key input 
signal to a keyboard input signal which is recognized by the operating system. 

10 By calling the selected object from the mapset, a keyboard input signal is 
produced and delivered into the keyboard stream of the computer. This is 
represented by keyboard stream 178. In the embodiment shown the keyboard 
stream is an input to the Windows NT® operating system. The keypad applet 
170 operates to sense the input through its corresponding key listener. Applet 

15 1 70 is also operative to receive the event and may operate to display an icon or 

other graphic corresponding to what the customer has input. 

Figure 28 shows operation of the keyboard mapper in situations where 
the transaction services application operates to prevent transmitting the data 
input by the customer to the applet 170. This may be desirable for example, in 

20 situations where the input by the customer is the customer's PIN or other data 
which is not to be displayed. In these circumstances the transaction services 
application 146 operates to hold the data input by the customer and to send 
only a signal representative of a holding character, in this case a symbol 
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back to the browser. This is done selectively in response to the instructions 
contained in documents accessed by the browser or in other HTTP records 
accessed by the computer which indicates that the input by the customer 
corresponds to their PIN or other data which is not to be sent to the browser. 

5 In the example shown in Figure 28 only the holding character is passed 

through the keyboard mapper to the browser. In situations where the HTTP 
record accessed invokes methods in which numerical values are to be sent to 
the browser and/or displayed on the screen (such as the amount of a 
withdrawal transaction) the signal sent by the transaction services application 

1 0 to the browser is indicative of the numerical value associated with the key 
pressed. 

Figure 30 is a further example of the operation of the keyboard mapper 
in this case the input corresponds to a function key 166. In this case the input 
is caused by pressing the function key "A" which is shown adjacent to the 

1 5 upper right hand corner of the screen as shown in Figure 27. The signal 

generated in response to pressing the function key is passed to the keyboard 
mapper which in response to the data obtained from the data store 176 outputs 
a mouse input corresponding to a mouse click. The mouse input includes data 
representative of the x and y coordinates on the screen where the mouse click 

20 is to be provided. This mouse input signal is passed to the mouse stream input 
schematically represented 1 80. 

As will be appreciated to enable the automated banking machine which 
processes HTML documents to operate using a conventional ATM interface 
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the mouse input will generally include coordinate locations which correspond 
to a location on the screen adjacent to the particular function key. This is 
because the icon, line, text or other indicia which the customer is selecting by 
pressing the key will preferably appear or extend on the screen adjacent to the 
key. In this way the customer is aware through the visual presentation what 
key to press to make a corresponding selection. A number of function keys 
adjacent to the screen may be operative at any one time. The customer may 
make selections by pressing a function key at one location and then a function 
key at another location disposed from the first location. This will result in 
signals being sent to the mouse stream corresponding to mouse clicks at 
coordinates on the screen adjacent to the function buttons pressed by the 
customer. During transactions various combinations of function and keypad 
keys may be operative and mapped to various keyboard and mouse inputs as 
determined by the selected mapsets. In addition developers may develop 
special mapsets corresponding to the particular graphics in HTML documents 
which are displayed. 

In the foregoing manner keypad inputs to a conventional ATM or other 
automated banking machine keypad can be translated into conventional 
keyboard or mouse inputs which can be identified and processed in a 
conventional keyboard input stream or mouse input stream to a computer. 
Likewise function keys may be translated into mouse inputs at selected 
locations and delivered into the mouse input stream for processing by the 
computer or may be converted into keyboard inputs and delivered to the 
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keyboard input stream. A further advantage of the described terminal 
configuration is that keys may be selectively disabled except when they are 
needed. This may reduce instances of attempts to improperly access the 
machine by pressing keys on the keyboard. Further as previously discussed 

5 steps may also be taken to disable keys when they are not needed to increase 
transaction processing speeds. 

A further advantage of embodiments of the present invention is the 
ability of the automated banking machine to provide printed documents based 
on instructions in HTML documents. Such printed items may include tickets, 

1 0 travelers checks, money orders, bank checks, scrip or other types of 

documents. The ability of preferred embodiments to access and process 
HTML documents enables the printing of graphics and other indicia which can 
produce printed documents having selected appearance features and selected 
ornamental designs. This can reduce the need to utilize preprinted forms and 

1 5 also enables the printing of a greater variety of printed formats. Further the 
configuration of some embodiments of the machine enable printing only 
selected portions of transaction information for record keeping purposes 
within the machine while providing versions including enhanced graphics or 
other attractive features to customers. 

20 Figure 31 is a schematic representation of the operation of the system 

in printing forms using a printer in an automated transaction machine. The 
preferred form of the invention uses the WIN32 printer services which operate 
under Windows NT® 4.0. In the exemplary transaction shown, the director 
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manager class 180 operating in the terminal theater portion 138 initiates a print 
receipt transaction by requesting a printer director 182 to print a receipt. The 
printer director in one preferred embodiment is a collection of instances of 
related JAVA beans which operate to carry out printing activities, and is one 

5 of the directors among the terminal directors 144. The printer director 
includes a print class which is schematically shown separately which is 
operative to invoke a print URL method. The printer class in the preferred 
embodiment includes access to the shared transaction data object which 
includes the customer specific information concerning the transaction that 

10 includes indicia representative of information to be printed. In the case of an 
automated banking machine this may include for example indicia 
representative information which is read from a customer's card input to the 
machine and read by a card reader. This would include for example the 
customer's name and account number. The other transaction information may 

1 5 include the types of transactions conducted such as a deposit, withdrawal or 
inquiry as well as the amount involved in each respective transaction. 

The transaction services application 146 receives the print request and 
passes the URL string to the WIN printer object 1 84 by the print URL method. 
The URL address in one preferred embodiment is the address of an HTTP 

20 record such as an HTML document that will be used to format the document 
to be printed, in this case a receipt. This HTML document contains the 
embedded JAVA script that processes transaction data from the transaction 
data object. The URL address of the document may be on a local machine or 
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may be retrieved from another server such as through a network schematically 
indicated 186. Network 186 may be a local area network or a wide area 
network depending on the configuration of the machine. 

The WIN printer object 1 84 next navigates to the address of the 

5 document to be accessed. This is done in the preferred embodiment using 
Microsoft's C Web Browser2 ActiveX control. When the HTML document 
has been loaded the ActiveX control automatically begins processing the 
content of the accessed document. The transaction services application 146 
invokes the print URL method of the WIN printer object 184. The WIN 

10 printer object uses the ActiveX control to print the current HTML document. 
This printing is processed by the Windows NT® print spool and graphics 
components. 

The JAVA CDI receives an event from the print monitor component 
192 that indicates the completion of print spooling. This indicates that a file is 
1 5 now available to be read and sent to the common device interface (CDI) 1 88 

of the receipt printer. 

Next a printer object 190 invokes a read data function in the print 
monitor 1 92 to determine the location and size of the print data file. The print 
object 190 sends the data or the path name of the data file to the printer CDI 
20 1 88. The printer CDI 1 88 then passes the print data to the printer hardware. 

This results in printing of the document. 

Once the receipt is printed the applet from the printer director 1 82 
issues a request to deliver the printed receipt. The delivery request is passed 
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through the transaction services application 146 to the printer object 190. The 
printer object 190 invokes the deliver method on the printer CDI 188 to cause 
the receipt to be delivered to the user of the machine. The operation of the 
software components enables selectively accessing document formats as well 
5 as using instructions contained in the documents to include transaction data 
within the printed documents. This enables producing documents of varied 
types. In addition it enables providing printing different types of documents 
for different customers. This may be desirable when providing marketing 
information, coupons or similar indicia on transaction receipts. This approach 
1 0 further simplifies providing printed formats in various languages by 

developing HTML documents which provide printed forms in different 
languages. In addition the methods of the present invention may be used for 
providing marketing to customers by profile or types of customer categories, 
as well as on a segment of one basis. 
1 5 While the printing method previously described is discussed in 

connection with delivering transaction receipts, similar methods may be 
invoked for the printing of statements for customers as well as for printing a 
transaction journal within the automated banking machine. Further by 
accessing selected documents controlling the format of printing the 
20 information journal records may be provided with consolidated information in 
a manner which enables conserving journal paper within the machine by not 
printing promotional or other types of information that is provided on 
customer documents. 
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The printing method of the present invention also enables printing 
various types of optical indicia such as bar code or other types of machine 
readable indicia which can be used for printing coupons, checks or similar 
articles. Such coding may facilitate tracking the use of such items by 
5 customers for purposes of evaluating the effectiveness of various marketing 
efforts. In addition machine readable indicia may be used for printing on 
items such as deposit envelopes and/or in transaction journals. Such printing 
may facilitate reading such items by machine to verify the contents of 
deposits. 

10 The printing capabilities achieved through the methods of the present 

invention also enables the printing of selected graphical materials. This may 
include for example materials which include imbedded digital signatures 
which can be used to verify the genuineness of the items printed. This may be 
particularly useful for example in situations where the transaction machine is 

1 5 used to print scrip, travelers checks, betting slips or other items having 
independent value. In addition printed documents in full color may be 
produced by including a color printer in the transaction machine. 

Computer software used in operating the automated transaction 
machines of the present invention and connected computers may be loaded 

20 from articles of various types into the respective computers. Such computer 
software may be included on and loaded from one or more articles such as 
diskettes or compact disks. Such software may also be included on articles 
such as hard disk drives, tapes or ready only memory devices. Other articles 
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which include data representative of the instructions for operating computers 
in the manner described herein are suitable for use in achieving operation of 
transaction machines and systems in accordance with embodiments of the 
present invention. 

5 The exemplary embodiments of the automated banking machines and 

systems described herein have been described with reference to particular 
software components and features. Other embodiments of the invention may 
include other or different software components which provide similar 
functionality. 

1 0 Thus the new automated banking machine and system of the present 

invention achieves the above stated objectives, eliminates difficulties 
encountered in the use of prior devices and systems, solves problems and 
attains the desirable results described herein. 

In the foregoing description certain terms have been used for brevity, 

1 5 clarity and understanding. However no unnecessary limitations are to be 

implied therefrom because such terms are for descriptive purposes and are 
intended to be broadly construed. Moreover the descriptions and illustrations 
herein are by way of examples and the invention is not limited to the details 
shown and described. 

20 In the following claims any feature described as a means for 

performing a function shall be construed as encompassing any means capable 
of performing the recited function and shall not be deemed limited to the 
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particular means shown in the foregoing description or mere equivalents 
thereof. 

Having described the features, discoveries and principles of the 
invention, the manner in which it is constructed and operated and the 
advantages and useful results attained; the new and useful structures, devices, 
elements, arrangements, parts, combinations, systems, equipment, operations, 
methods, processes and relationships are set forth in the appended claims. 
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CLAIM? 

We claim: 

1 . A method comprising the steps of: 

(a) checking to determine whether a document address is 
operative to enable transferring at least one HTTP 
record corresponding to the address, with a computer 
operating in an automated banking machine; and 

(b) responsive to determining with the computer program in 
step (a) that the address is operative, transferring the 
one HTTP record to the computer operating in the 
automated banking machine. 

2. The method according to claim 1 wherein in step (a) the HTTP 
record includes an HTML document and wherein step (b) includes accessing 
the HTML document with a browser operative in the computer of the 
automated banking machine. 

3. The method according to claim 1 wherein responsive to 
determining in step (a) that the address is not operative, step (b) is not 
executed, and further comprising the step of: 

(c) responsive to determining in step (a) that the address is 
not operative, transferring at least one alternative I ITTP 
record to the computer from an alternative address. 

4. The method according to claim 3 and prior to the step (c) 
further comprising the step of: 
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(d) checking to determine whether the alternative address is 
operative to enable transferring the at least one 
alternative HTTP record with the computer operating in 
the machine, wherein step (c) is executed responsive to 
determining that the alternative address is operative. 

5. The method according to claim 3 wherein the computer in the 
banking machine is in operative connection with a memory, and wherein the 
alternative address corresponds to address data stored in the memory, and 
prior to step (c) further comprising the step of accessing with the computer the 
address data stored in the memory, and using the address data to determine the 
alternative address used in step (c). 

6. The method according to claim 3, and prior to step (c) further 
comprising the steps of: 

(d) responsive to determining with the computer in step (a) 
that the address is not operative, accessing a further 
HTTP record with the computer, wherein the further 
HTTP record includes address data; and 

(e) determining with the computer the alternative address 
from the address data in the further HTTP record. 

7. The method according to claim I wherein the automated 
banking machine includes a sheet dispenser, and wherein the one 1 ITTP record 
includes a dispense instruction, and further comprising the step of: 

(c) dispensing at least one sheet with the sheet dispenser 
responsive to the dispense instruction in (he one* I DTP 
record accessed in step (h). 
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8. The method according to claim 1 wherein the automated 
banking machine includes a transaction function device, and wherein the one 
HTTP record includes a device instruction, and further comprising the step of: 

(c) operating the transaction function device responsive to 
the device instruction in the one HTTP record accessed 
in step (b). 

9. The method according to claim 8 and wherein the one HTTP 
record includes data corresponding to a signature, and wherein the computer is 
in operative connection with a memory, wherein the memory includes 
signature data corresponding to at least one signature, and prior to step (c) 
further comprising the step of: 

(d) comparing the signature in the one HTTP record and the 
signature data in the memory with the computer, and 
executing step (c) responsive to the signature in the one 
HTTP record having a predetermined relationship to the 
signature data stored in memory. 

10. The method according to claim 1 wherein step (a) includes 
making a socket connection with a remote server. 

1 1 . Computer software operating an automated banking machine in 
accordance with the method recited in claim 1 . 

12. The method according to claim I and prior lo completion of 
step (b) further comprising the step of: 

(c) determining a transfer speed at which the one I NTP 
record is transferable lo the computer. 



CA 02271212 1999-05-07 



96 D1077+12 
The method according to claim 12 and further comprising the 

(d) comparing data corresponding to the transfer to data 
representative of a speed value stored in memory with the 
computer; and 

(e) responsive to the results of the comparison in step (d), 
transferring at least one alternative HTTP record to the 
computer from an alternative address. 

Apparatus comprising: 

an automated banking machine including: 

at least one transaction function device; 

a computer in operative connection with the transaction 
function device; 

software executable in the computer, wherein the 
software is operative to transfer at least one HTTP 
record at a document address to the computer, and 
wherein the one record includes at least one device 
instruction, wherein the computer operates the 
transaction function device responsive to the device 
instruction included in the one record, and wherein the 
software further includes a program, wherein prior to 
transferring the one HTTP record the program is 
opcralivc to cause the computer to determine if Ihc 
record address is operative to enable accessing Ihc one 
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record, and wherein the computer operates to transfer 
the one HTTP record responsive to the program 
determining that the address is operative. 

15. The apparatus according to claim 14 wherein the software in 
5 the computer includes a browser, and wherein the one HTTP record includes 

an HTML document, and wherein the computer operates to transfer the HTML 
document by accessing the document with the browser. 

16. The apparatus according to claim 14, wherein the computer is 
operative responsive to the program determining that the address is not 

10 operative to determine an alternative record address, and further comprising at 
least one alternative HTTP record including device instructions is accessible at 
the alternative address, and wherein the computer is operative to access the 
alternative HTTP record. 

1 7. The apparatus according to claim 1 6 wherein the program is 

1 5 further operative prior to the computer accessing the alternative HTTP record 

to cause the computer to determine if the alternative address is operative to 
enable accessing the alternative HTTP record, and wherein the computer 
operates to transfer the alternative HTTP record responsive to determining that 
the alternative address is operative. 

20 1 8. The apparatus according to claim 14 and further comprising a 

server, and wherein the one HTTP record is accessible through the server, and 
wherein program operates such that prior to the computer operating to access 
the one HTTP record the program operates the computer lo determine if the 
server is operative. 

25 19. The apparatus according to claim 16 and further comprising u 

memory wherein the computer is in operative connection with the memory, 
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and wherein the memory includes address data, and wherein the computer is 
operative to determine the alternative address responsive to the address data. 

20. The apparatus according to claim 19 wherein the address data 
corresponds to a further HTTP record, and wherein the computer is operative 

5 to access the further HTTP record, and wherein the further HTTP record 
includes address instructions corresponding to the alternative address, and 
wherein the software is operative to cause the computer to determine the 
alternative address responsive to the address instructions. 

2 1 . The apparatus according to claim 1 4 wherein the transaction 
10 function device includes a sheet dispenser, and wherein the sheet dispenser is 

operative to dispense at least one sheet responsive to the device instruction 
included in the one HTTP record. 

22. The apparatus according to claim 14 and wherein the software 
includes a further program, wherein the further program is operative to cause 

1 5 the computer to determine a value corresponding to a transfer speed for 
transfer of the one HTTP record to the computer. 

23. The apparatus according to claim 22 and further comprising a 
memory in operative connection with the computer, and wherein the further 
program is operative to operate the computer to compare the transfer speed to 

20 data representative of a value stored in memory, and wherein the software is 
operating to access an alternative HTTP record responsive to a result of the 
comparison, whereby an alternative record may be accessed responsive to the 
one HTTP record transferring too slowly, 

24. The apparatus according to claim 22 wherein the software is 
25 operative to cause the computer to determine a file size corresponding to Ihc 
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one HTTP record and a transfer rate, and wherein the transfer speed is 
determined responsive to the file size and the transfer rate. 

25. The apparatus according to claim 24 wherein the one HTTP 
record includes an HTML document. 
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ABSTRACT 

An automated banking machine (12) is operative to conduct 
transactions in response to HTML documents and TCP/IP messages 
exchanged with a local computer system (14) through an intranet (16), as well 

5 as in response to messages exchanged with foreign servers (20, 22, 24, 26, 28, 
96) in a wide area network (18). The banking machine includes a computer 
(34) having an HTML document handling portion (76, 80, 82). The HTML 
document handling portion is operative to communicate through a proxy 
server (88), with a home HTTP server (90) in the intranet or the foreign 

10 servers in the wide area network. The computer further includes a device 

application portion (84) which interfaces with the HTML document handling 
portion and dispatches messages to operate devices (36) in the automated 
banking machine. The devices include a sheet dispenser mechanism (42) 
which dispenses currency as well as other transaction devices. The device 

1 5 application portion communicates with a device interfacing software portion 
(64) in the banking machine through a device server (92) in the intranet. The 
device server maintains local control over the devices in the banking machine 
including the sheet dispenser. The banking machine operates to read indicia 
on the user's card corresponding to a system address. The computer is 

20 operative to connect the banking machine to the home or foreign server 
corresponding to the system address, which connected server operates the 
banking machine until the completion of transactions by the user. 
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